Alternative templating schemes

Dominic_Watson · February 13, 2015, 9:11am

I think what would be interesting to see is how Dave is using his CFC based
views and see if there is a language enhancement that can meet those needs
when not using a framework.

Something that ColdBox (and I’m sure almost any other MVC framework) offers
is the ability to do:

rendered = renderView( view=“/path/to/view”,
args=StructOfDataToMakeAvailable );

This, combined with good use of in the view to DECLARE what
arguments it expects, is a really clean way to have self contained
declarative views.

<!— <<< throws
a really helpful error if the variable is not made available to the view
—>

However, there is a bit of a hack going on here. The view must be included
into the renderer CFC using and thus shares the renderer CFCs
scope (and there’s a bunch of baggage and complexity there that would be
good to avoid).

What would be interesting to play with, is a core language feature to
render a view completely in its own context so that it is entirely self
contained (similar to cfmodule but without the starttag/endtag stuff). The
view then becomes like a standalone CFC with its own API for rendering
(params that it declares that it needs).

rendered = renderTemplate( template=“/path/to/template.lucee”,
arguments=dataIWantAvailableToTemplate );

This can of course be achieved with frameworks, and perhaps that’s where it
belongs - but maybe worthwhile exploring.On 13 February 2015 at 08:53, Michael Offner <@Michael_Offner> wrote:

see my comments between the lines

Micha

On Fri, Feb 13, 2015 at 2:39 AM, Kai Koenig <@Kai_Koenig> wrote:

the main difference between you (plural) and I is that you try to
push me to do things your way, while I prefer to keep my options open

I would strongly debate that, but that’s a different discussion.

Kai – the fact that you don’t understand something doesn’t make it
bullsh*t. I’ve always treated you with respect – it’d be nice if you’d
try to do the same

Just to make things clear - the bullish*t comment was not targeting you
in particular but anyone in this discussion trying to convince me of
breaking away from common-sense separation of concerns architectural
principles without providing a use case why their proposed solution is
better.

Se my argument about it, i’m not only gives you a theoretical anwser, no
my example include a working solution that has a big benefit by not
separation the view layer from the bussiness logic, in one word
“simplification”!

Now you HAVE supplied such a case (see below) and we can discuss your
argument. That has nothing to do with not understanding something at all.

I will try to show an example of what I mean, hopefully the
oversimplification will not make it miss the point

a) I don’t see how the approach below differs from what Abram’s said:

"So, what would stop you from just including a cfm file with your UI
stuff if you want it inside a cfc? To me that is the cleaner approach.”

simplification, i dont want to map view templates seperatly in any case, i
dont want this sepration.

To me, that’d be a much clearer approach, too, instead of sticking markup
into a component. If you really wanted to have a UIRenderer component.

cleaner but more complicated

b) Let’s assume you did NOT have tags in components, how would this
requirement be solved nicely?

echo(“
”);

Option 1)
Script component including a tag/markup file. That’s essentially the
CFML-based version of a mixin (well, -ish) and I don’t think there’s
anything wrong with that.

maybe we could talk about how this files are included, maybe we could
bundle them with a component

Option 2)
Don’t have a UIRenderer component but have tag-based custom tags for
rendering your widget (lists) or pagination etc. THAT is what tag-based
custom tags are really good at and useful for. Then on your page it’d
actually uses the custom tags which probably fits nicely into whatever
layout templating or page wrapper setup you prefer.

We have a saying, “all roads lead to rome”, what means your idea is a good
one, but it is for sure not the only one, limitation is most a good things
but in my personal view not in this case!

Personally, I think option 2 is much to be preferred as it separates
rendering (tag based in custom tags or templates) from business logic
(script based in components) very nicely.

Cheers
Kai

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/BC3F190A-2FCF-4F47-A179-C148A86BE835%40gmail.com
.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEBwDBgDBPRcSMCvcqKyy1Xqw4vyDutO112qPo-p1N%2BgaNw%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEBwDBgDBPRcSMCvcqKyy1Xqw4vyDutO112qPo-p1N%2BgaNw%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

–
Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn
http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB

Adam_Cameron1 · February 13, 2015, 1:37am

Oh fuck off Igal.

I assure you that is not the chief difference between you (singular)
and myself and Kai.

right. you’re also an asshole!

It’s more that I dislike being patronised(*), specifically when I’m also
not in the mood to suffer fools gladly. Which, admittedly, is most of the
time.On Friday, 13 February 2015 14:17:21 UTC+13, Igal wrote:

–
Adam

(*) and, yes, I get the irony of me saying this.

micstriit · February 13, 2015, 8:17am

I like to answer that, because for me that is the main reason I need tag
support in components.
The code I do never has components within the webroot, my components are in
a separate components folder outside the webroot and mapped with a
component mapping, as best as an archive on the published website.
In my experience mixing components with cfm templates is a bad
architectural choice!

Of course cfm templates cannot be inside a component mapping, so this makes
it very hard to link them with components.
So the easiest way is to do the view layer in a component as well.

Take for example the testbox integration in our testsuite, for that I’m
integrating testbox with a single component mapping
https://bitbucket.org/lucee/lucee/src/dec1bd097411a7430703e76ac2783310187c900e/tests/Application.cfc?at=master#cl-30

Problem I had was the renderer for the output, it was using a single cfm
template to make the output, I have integrated this into the renderer, so I
need no additional template mapping for that single file
https://bitbucket.org/lucee/lucee/src/dec1bd097411a7430703e76ac2783310187c900e/lucee-java/lucee-core/src/resource/component/org/lucee/cfml/test/reporter/HTMLReporter.cfc?at=master

This way I can integrate testbox with a single file and that single file
not even has to be on my machine!

this.componentpaths = [{archive:“http://ortus.com/latest/testbox.lar”}];

MichaOn Thu, Feb 12, 2015 at 11:31 PM, Abram Adams <@Abram_Adams> wrote:

So, what would stop you from just including a cfm file with your UI stuff
if you want it inside a cfc? To me that is the cleaner approach.

On Thursday, February 12, 2015 at 2:25:29 PM UTC-8, Igal wrote:

I disagree.

there are many times where tags makes sense in a component.

while most of the components (and even in templates) I write cfscript, in
most projects I have a component named UIRenderer, which contains many
reusable functions for rendering elements. that way the rendering output
is centralized, maintainable, and consistent across the project.

island tags would be my preferred way, since I would be able to use
script for the rest of the component, but there is definitely room for html
tags in components. unfortunately, as it is now, you can have an island
script in a tag based component, but not the other way around.

and the fact that there are frameworks out there is irrelevant. I don’t
use any of those, and for the foreseen future I don’t intend to start.

Igal Sapir
Lucee Core Developer
Lucee.org http://lucee.org/
On 2/12/2015 2:08 PM, Adam Cameron wrote:

On 12 February 2015 at 19:38, Dave Merrill enig...@gmail.com wrote:

Sean and Kai, can you explain why component-based views seem like such a
bad idea to you?

You didn’t ask me, but that’s never stopped me before.

I think there’s sufficient frameworks out there that allow one to
separate views out into separate view templates, it’s almost more a case of
why would you want to put your views into a CFC file?

Each view is best stored by itself, so that ppl maintaining the view -
who are often UI devs not business logic devs - have less scope for…
erm… “getting confused”, and it’s also a more familiar paradigm: a view
file is more similar to a web page than a component with a function with a
view in it.

Also a view should be as simple as possible. One of the main tenets of
MVC is separation of logic; with the view being purely display layer. So
the less logic a view has, the closer it is to being an ideal view.

So the closest one could get to an “ideal view” would be to have one
view per CFC. Which means that one is left with a bunch of irrelevant
boilerplate code in there to define the CFC and the function, and the
arguments etc before getting to the code that actually matters to the
view.

And why do that if one can just do the view in a CFM file, and leave it
to simply get on with being a view?

One can drive a screw in with a hammer rather than a screwdriver. And
that works. But there’s more to “it working” than the end result being “the
screw is now embedded in the wood”.

–
Adam

You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/lucee/CAFwR%2BKd_k5y37p84EJ-2C09nyzDqyi8CKzVy32-
OyjUJMvyB8w%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAFwR%2BKd_k5y37p84EJ-2C09nyzDqyi8CKzVy32-OyjUJMvyB8w%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/a523ef43-f4f2-4777-9ee2-2f14402579c6%40googlegroups.com
https://groups.google.com/d/msgid/lucee/a523ef43-f4f2-4777-9ee2-2f14402579c6%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

Dominic_Watson · February 13, 2015, 9:36am

Right, so did an experiment. The following code produces a shed load of
extraneous whitespace and I’d personally prefer that it didn’t (by default):

#( new TestCfc().testMethod()
)#

// TestCfc.cfc

<cffunction name="testMethod">

    <cfreturn "something" />
</cffunction>

But as you point out Micha, the script based components do not leak that
whitespace by default (so that’s great):

// TestCfc.cfc (no whitespace produced)
component {

function testMethod() {

    return "some text";

}

}

But of course, if we’re suggesting no tag based CFCs I guess its a mute
point.On 13 February 2015 at 09:28, Dominic Watson <@Dominic_Watson> wrote:

To stop your developers from doing it in the first place and, from a
language perspective, lead people away from that approach. Tough to change
for .cfc extension - but IF we really are to have a new dialect, I think it
would be worth reviewing.

I can, of course, change the defaults of tag attributes in Application.cfc
(thanks for that btw, awesome).

Also, I always did output=false on functions due to whitespace production
issues. I’ll experiment now to see if that really still is the case.

On 13 February 2015 at 09:22, Michael Offner <@Michael_Offner> wrote:

the attribute output is only really necessary with tag based components,
then only they produce output “on their own”.
script based code only producing output when you do a echo(…), so why
suppress your own actions by default?

Micha

On Fri, Feb 13, 2015 at 10:18 AM, Dominic Watson < @Dominic_Watson> wrote:

If that were a .lucee.cfc (or whatever), I’d like to see that
output=false would be default. I would strongly discourage that kind of use
of a CFC function and be pleased if the language to a lead in doing so too.
i.e. why have the function output anything when it can return the value:

component {
public string function markdownTitleAndDescription( required string
title, required string description ) output=false {
return “##” & title & "##
" & description;
}
}

…

#markdownHelper.markdownTitleAndDescription( ‘title’, ‘lorem ipsum…’ )#

–
Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB

–
You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAEYvUx%3Ddj3g1txWR0AA-YT68ms%3D6xA9XpUXT%2BD%3DDmknXfyqqKQ%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAEYvUx%3Ddj3g1txWR0AA-YT68ms%3D6xA9XpUXT%2BD%3DDmknXfyqqKQ%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEBx%2B18iB%2BeDO65SLNhM3rOeZzEkip%3Dz2XRYNS053wX4kpw%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEBx%2B18iB%2BeDO65SLNhM3rOeZzEkip%3Dz2XRYNS053wX4kpw%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

–
Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB

–
Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn
http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB

Adam_Cameron1 · February 13, 2015, 7:37pm

Think about typical business workflows. As developers our end users are
typically not just the visitors to that come to our site/app. We are often
not the only ones who need to work with the view. When you closely couple
the view with the business logic and model you are making it much more
difficult to maintain. Sure it is easier for you, but should that be
what we strive for? Best practices aren’t just to save me a keystroke, or
to prevent me from having to maintain code in two separate files, they are
there to collectively organize the entire application in a maintainable way.

Programming practices are almost never about saving keystrokes and time for
the person writing the initial code. And any justification of a practice
based on that are generally invalid. Code is written once and maintained
many many many times, and this is where the separation of concerns comes
in. If I am needing to fix something in a view (or some view code), then I
should not be touching the same file where the business logic is housed.

Taking your example further. What happens when I now want a slightly
different style or layout? Do I end up with html1() html2(), and now I
want a mobile version: htmlMobile()? That pattern makes it much more
difficult to reuse these functions.

Correct.

Maybe I’ve thinking about this wrong, and am really looking for valid
reasons why, but yet I still don’t see any. The argument of being easy
is very one-sided and very short-sighted, tbh. I do a fair bit of contract
work and have worked on various legacy systems that were done the “easy
way”. Trust me, that wasn’t “easy” for me, and it wasn’t cheap for my
clients either.

Also correct.On 14 February 2015 at 06:19, Abram Adams <@Abram_Adams> wrote:

–
Adam

Dominic_Watson · February 13, 2015, 9:18am

If that were a .lucee.cfc (or whatever), I’d like to see that output=false
would be default. I would strongly discourage that kind of use of a CFC
function and be pleased if the language to a lead in doing so too. i.e. why
have the function output anything when it can return the value:

component {
public string function markdownTitleAndDescription( required string
title, required string description ) output=false {
return “##” & title & "##
" & description;
}
}

…

#markdownHelper.markdownTitleAndDescription( ‘title’, ‘lorem ipsum…’ )#–
Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn
http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB

micstriit · February 13, 2015, 5:57pm

This comment is there because I simply took the external template and I
have included it in the component with as less effort as possible and this
could be done better.
But that is not the point, I did this that I can use testbox in a single
file with one configuration. That is my argument! Show me a example where
you can do the same with a external template!

MichaAm Freitag, 13. Februar 2015 schrieb Abram Adams :

From your example, I do agree with this line:

Bitbucket

Functions shouldn’t output content, but rather should return and the view
layer should decide how to output it. In your example you’re calling
html() like:

savecontent variable=“local.report”{
html(results,testbox,options,baseURL);
}

if you were just returning the html string from html() it would be as
simple as:
local.report = html(results,testbox,options,baseURL);

Think about typical business workflows. As developers our end users are
typically not just the visitors to that come to our site/app. We are often
not the only ones who need to work with the view. When you closely couple
the view with the business logic and model you are making it much more
difficult to maintain. Sure it is easier for you, but should that be
what we strive for? Best practices aren’t just to save me a keystroke, or
to prevent me from having to maintain code in two separate files, they are
there to collectively organize the entire application in a maintainable way.

Taking your example further. What happens when I now want a slightly
different style or layout? Do I end up with html1() html2(), and now I
want a mobile version: htmlMobile()? That pattern makes it much more
difficult to reuse these functions.

Maybe I’ve thinking about this wrong, and am really looking for valid
reasons why, but yet I still don’t see any. The argument of being easy
is very one-sided and very short-sighted, tbh. I do a fair bit of contract
work and have worked on various legacy systems that were done the “easy
way”. Trust me, that wasn’t “easy” for me, and it wasn’t cheap for my
clients either.

On Friday, February 13, 2015 at 12:17:46 AM UTC-8, Micha wrote:

I like to answer that, because for me that is the main reason I need tag
support in components.
The code I do never has components within the webroot, my components are
in a separate components folder outside the webroot and mapped with a
component mapping, as best as an archive on the published website.
In my experience mixing components with cfm templates is a bad
architectural choice!

Of course cfm templates cannot be inside a component mapping, so this
makes it very hard to link them with components.
So the easiest way is to do the view layer in a component as well.

Take for example the testbox integration in our testsuite, for that I’m
integrating testbox with a single component mapping
Bitbucket
10187c900e/tests/Application.cfc?at=master#cl-30

Problem I had was the renderer for the output, it was using a single cfm
template to make the output, I have integrated this into the renderer, so I
need no additional template mapping for that single file
Bitbucket
10187c900e/lucee-java/lucee-core/src/resource/component/
org/lucee/cfml/test/reporter/HTMLReporter.cfc?at=master

This way I can integrate testbox with a single file and that single file
not even has to be on my machine!

this.componentpaths = [{archive:“http://ortus.com/latest/testbox.lar”}];

Micha

On Thu, Feb 12, 2015 at 11:31 PM, Abram Adams cfxc...@gmail.com wrote:

So, what would stop you from just including a cfm file with your UI
stuff if you want it inside a cfc? To me that is the cleaner approach.

On Thursday, February 12, 2015 at 2:25:29 PM UTC-8, Igal wrote:

I disagree.

there are many times where tags makes sense in a component.

while most of the components (and even in templates) I write cfscript,
in most projects I have a component named UIRenderer, which contains many
reusable functions for rendering elements. that way the rendering output
is centralized, maintainable, and consistent across the project.

island tags would be my preferred way, since I would be able to use
script for the rest of the component, but there is definitely room for html
tags in components. unfortunately, as it is now, you can have an island
script in a tag based component, but not the other way around.

and the fact that there are frameworks out there is irrelevant. I
don’t use any of those, and for the foreseen future I don’t intend to start.

Igal Sapir
Lucee Core Developer
Lucee.org http://lucee.org/
On 2/12/2015 2:08 PM, Adam Cameron wrote:

On 12 February 2015 at 19:38, Dave Merrill enig...@gmail.com wrote:

Sean and Kai, can you explain why component-based views seem like such
a bad idea to you?

You didn’t ask me, but that’s never stopped me before.

I think there’s sufficient frameworks out there that allow one to
separate views out into separate view templates, it’s almost more a case of
why would you want to put your views into a CFC file?

Each view is best stored by itself, so that ppl maintaining the view

who are often UI devs not business logic devs - have less scope for…
erm… “getting confused”, and it’s also a more familiar paradigm: a view
file is more similar to a web page than a component with a function with a
view in it.

Also a view should be as simple as possible. One of the main tenets
of MVC is separation of logic; with the view being purely display layer. So
the less logic a view has, the closer it is to being an ideal view.

So the closest one could get to an “ideal view” would be to have one
view per CFC. Which means that one is left with a bunch of irrelevant
boilerplate code in there to define the CFC and the function, and the
arguments etc before getting to the code that actually matters to
the view.

And why do that if one can just do the view in a CFM file, and leave
it to simply get on with being a view?

One can drive a screw in with a hammer rather than a screwdriver. And
that works. But there’s more to “it working” than the end result being “the
screw is now embedded in the wood”.

–
Adam

You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/ms
gid/lucee/CAFwR%2BKd_k5y37p84EJ-2C09nyzDqyi8CKzVy32-OyjUJMvy
B8w%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAFwR%2BKd_k5y37p84EJ-2C09nyzDqyi8CKzVy32-OyjUJMvyB8w%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/lucee/a523ef43-f4f2-4777-9ee2-2f14402579c6%40googlegroups.com
https://groups.google.com/d/msgid/lucee/a523ef43-f4f2-4777-9ee2-2f14402579c6%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/7b152c60-c6e8-4b18-8953-fc3904a5b618%40googlegroups.com
https://groups.google.com/d/msgid/lucee/7b152c60-c6e8-4b18-8953-fc3904a5b618%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

markdrew · February 13, 2015, 9:46am

Having markup or output code in Components is not a common thing I thin owe are agreed. There are cases where you need to have it but I would rather see a function that wraps up this:

function render(){

	var welcomeMailVars = { … some vars …};
	savecontent variable=“ret” {
		include template=“/templates/mail/welcomemail.cfm”;
	}	

	return ret;
}

into something more elegant… something like (and please don’t kill me, I am just suggesting this as I can’t think of anything better):

function render {

	var welcomeMailVars = { … some vars …};
	return savecontent template=“/templates/mail/welcomemail.cfm” variables=“ welcomeMailVars”;
}

The idea of rendering a template with the passed variables and getting the string back stops a lot of crappy concatenation (which for some reason gave me nightmares in my ASP days)

Mark Drew

develop • deploy • deliver
http://charliemikedelta.com ttp://charliemikedelta.com> On 13 Feb 2015, at 09:36, Dominic Watson <@Dominic_Watson> wrote:

Right, so did an experiment. The following code produces a shed load of extraneous whitespace and I’d personally prefer that it didn’t (by default):

#( new TestCfc().testMethod() )#

// TestCfc.cfc
<cffunction name="testMethod">

    <cfreturn "something" />
</cffunction>
But as you point out Micha, the script based components do not leak that whitespace by default (so that’s great):

// TestCfc.cfc (no whitespace produced)
component {
function testMethod() {

    return "some text";

}
}

But of course, if we’re suggesting no tag based CFCs I guess its a mute point.

On 13 February 2015 at 09:28, Dominic Watson <@Dominic_Watson mailto:Dominic_Watson> wrote:
To stop your developers from doing it in the first place and, from a language perspective, lead people away from that approach. Tough to change for .cfc extension - but IF we really are to have a new dialect, I think it would be worth reviewing.

I can, of course, change the defaults of tag attributes in Application.cfc (thanks for that btw, awesome).

Also, I always did output=false on functions due to whitespace production issues. I’ll experiment now to see if that really still is the case.

On 13 February 2015 at 09:22, Michael Offner <@Michael_Offner mailto:Michael_Offner> wrote:
the attribute output is only really necessary with tag based components, then only they produce output “on their own”.
script based code only producing output when you do a echo(…), so why suppress your own actions by default?

Micha

On Fri, Feb 13, 2015 at 10:18 AM, Dominic Watson <@Dominic_Watson mailto:Dominic_Watson> wrote:
If that were a .lucee.cfc (or whatever), I’d like to see that output=false would be default. I would strongly discourage that kind of use of a CFC function and be pleased if the language to a lead in doing so too. i.e. why have the function output anything when it can return the value:

component {
public string function markdownTitleAndDescription( required string title, required string description ) output=false {
return “##” & title & "##
" & description;
}
}

…

#markdownHelper.markdownTitleAndDescription( ‘title’, ‘lorem ipsum…’ )#

–
Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom
T: +44 [0] 845 260 0726 <>• W: www.pixl8.co.uk http://www.pixl8.co.uk/• E: info@pixl8.co.uk mailto:info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter http://www.twitter.com/pixl8 LinkedIn http://www.linkedin.com/pixl8
CONFIDENTIAL AND PRIVILEGED - This e-mail and any attachment is intended solely for the addressee, is strictly confidential and may also be subject to legal, professional or other privilege or may be protected by work product immunity or other legal rules. If you are not the addressee please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead, please email it back to the sender and then immediately permanently delete it. Pixl8 Interactive Ltd Registered in England. Registered number: 04336501. Registered office: 8 Spur Road, Cosham, Portsmouth, Hampshire, PO6 3EB

–
You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAEYvUx%3Ddj3g1txWR0AA-YT68ms%3D6xA9XpUXT%2BD%3DDmknXfyqqKQ%40mail.gmail.com https://groups.google.com/d/msgid/lucee/CAEYvUx%3Ddj3g1txWR0AA-YT68ms%3D6xA9XpUXT%2BD%3DDmknXfyqqKQ%40mail.gmail.com?utm_medium=email&utm_source=footer.

For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBx%2B18iB%2BeDO65SLNhM3rOeZzEkip%3Dz2XRYNS053wX4kpw%40mail.gmail.com https://groups.google.com/d/msgid/lucee/CAG%2BEEBx%2B18iB%2BeDO65SLNhM3rOeZzEkip%3Dz2XRYNS053wX4kpw%40mail.gmail.com?utm_medium=email&utm_source=footer.

For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.

–
Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom
T: +44 [0] 845 260 0726 <>• W: www.pixl8.co.uk http://www.pixl8.co.uk/• E: info@pixl8.co.uk mailto:info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter http://www.twitter.com/pixl8 LinkedIn http://www.linkedin.com/pixl8
CONFIDENTIAL AND PRIVILEGED - This e-mail and any attachment is intended solely for the addressee, is strictly confidential and may also be subject to legal, professional or other privilege or may be protected by work product immunity or other legal rules. If you are not the addressee please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead, please email it back to the sender and then immediately permanently delete it. Pixl8 Interactive Ltd Registered in England. Registered number: 04336501. Registered office: 8 Spur Road, Cosham, Portsmouth, Hampshire, PO6 3EB

–
Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom
T: +44 [0] 845 260 0726 <>• W: www.pixl8.co.uk http://www.pixl8.co.uk/• E: info@pixl8.co.uk mailto:info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter http://www.twitter.com/pixl8 LinkedIn http://www.linkedin.com/pixl8
CONFIDENTIAL AND PRIVILEGED - This e-mail and any attachment is intended solely for the addressee, is strictly confidential and may also be subject to legal, professional or other privilege or may be protected by work product immunity or other legal rules. If you are not the addressee please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead, please email it back to the sender and then immediately permanently delete it. Pixl8 Interactive Ltd Registered in England. Registered number: 04336501. Registered office: 8 Spur Road, Cosham, Portsmouth, Hampshire, PO6 3EB

–
You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAEYvUxkhB40coSs1bCDp6cTSmzf-qHK0zuoo7Q_fTNsu7PLFtA%40mail.gmail.com https://groups.google.com/d/msgid/lucee/CAEYvUxkhB40coSs1bCDp6cTSmzf-qHK0zuoo7Q_fTNsu7PLFtA%40mail.gmail.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.

micstriit · February 13, 2015, 8:22am

@Kai
I did not say “tag based custom tags”, it was “cfm” vs. “cfc”, my problem
with “CFM based custom tags” is that they have a different approach with
scoping like I explained in detail, I don’t want to have because in a clean
start i don’t need 2 different scoping concepts.
Like i also question 2 scopes with the same range and the same lifecycle.

MichaOn Fri, Feb 13, 2015 at 1:37 AM, Kai Koenig <@Kai_Koenig> wrote:

So, what would stop you from just including a cfm file with your UI
stuff if you want it inside a cfc? To me that is the cleaner approach.
this is like asking “why do we need functions or custom tags in the
language when we can just write the function’s body into a snippet and use
cfinclude…”

there are times when you want to include a snippet/template, there are
times when you want to use custom tags, and there are times when you want
to use functions.

Two notes:

Funny, in another thread I was told by Micha that tag-based custom tags
are bad and should not exist — that we all should use component-based
custom tags because it’s all about the simplification and cleanup of the
language…

Unless someone finally provides a realistic and non-abstract (“there
are times when…”) appropriate use case of using tags over script in a
component, I will continue to call bullsh*t on people who suggest that’d be
a good idea in language design in this or any other parallel universe.

Cheers
Kai

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/BEF9AFA4-67FD-4EE5-86B3-2098B935076B%40gmail.com
.
For more options, visit https://groups.google.com/d/optout.

Robert_Munn · February 13, 2015, 8:06pm

Having markup or output code in Components is not a common thing I thin owe are agreed. There are cases where you need to have it but I would rather see a function that wraps up this:

function render {
  var welcomeMailVars = { … some vars …};
  return savecontent template=“/templates/mail/welcomemail.cfm” variables=“ welcomeMailVars”;
}

The idea of rendering a template with the passed variables and getting the string back stops a lot of crappy concatenation (which for some reason gave me nightmares in my ASP days)

That kind of syntax is essentially how Mustache templating works, e.g. $.Mustache.render( “welcomemail”, welcomeMailVars );

which you can return, assign to a variable, or add to the DOM on the client.

Mostly I don’t do server-side output in apps these days, but to the extent I do, I use tag libraries like a templating engine. If there were a built in way to use tag libraries in script, e.g.

import taglib=‘mail’ prefix=‘mail’

savecontent tag=mail.welcomemail variables=welcomeMailVars;

Although I would prefer rendering to work like a function:

render( [template=string.] [tag=string,] args );

and assign that to a variable, return it, etc.On Feb 13, 2015, at 1:46 AM, Mark Drew <@Mark_Drew> wrote:

Jean_Moniatte · February 13, 2015, 9:18am

If I understand properly (96 messages down now), the consensus on this
would be to keep custom tags in the language, right?

If there is a vote to give, it would be a “yes please” for me, I find them
very useful and elegant for rendering resultsets as well as for managing
forms elements :

<form:field type=“text” name=“username” value=“” message="Enter your

username">
<form:field type=“datepicker” name=“birthdate” value=“01/01/1982”>
…

Thanks,
Jean–
Jean Moniatte
UGAL
@Jean_Moniatte
http://www.ugal.com

On Fri, Feb 13, 2015 at 10:09 AM, Michael Offner <@Michael_Offner> wrote:

one comment to this, we are only speaking about have extrernal files to
produce html.

What is nothing else than information formatted in a specific way (html)
for a specific purpose (show in browser).
So we provide an interface for a specific client, but that is for sure not
the only interface we provide, we can and do provide interfaces for all
kind of client text and binary based, so does this mean that i have to do
everything I write to the response stream of a client in an external
template or only html?
Take this example:
component {
function produceMarkdown(string title, string text){
echo(“##”&title&"##
"&text);
}
}

following your logic I need to move this to an external template because
we need to separate business logic from output in any case, right? or is
this different and if so why?
Who is defining where we draw the line?
Then they are cases where it makes sense to produce output in a component
and some maybe not, but in my opinion it is NOT up to the engine to decide!

Micha

On Fri, Feb 13, 2015 at 6:04 AM, Kai Koenig <@Kai_Koenig> wrote:

Option 2)
Don’t have a UIRenderer component but have tag-based custom tags for
rendering your widget (lists) or pagination etc. THAT is what tag-based
custom tags are really good at and useful for. Then on your page it’d
actually uses the custom tags which probably fits nicely into whatever
layout templating or page wrapper setup you prefer.

Personally, I think option 2 is much to be preferred as it separates
rendering (tag based in custom tags or templates) from business logic
(script based in components) very nicely.
right. that’s the way I used to do it before components were introduced
into the language. but

it proved to be much slower to begin with.

by using functions I can use cachedWithin, so for example, if I pass
a widgetId and the function has to do a lookup to get more details (like
name, price, etc), this can all be cached by Lucee internally, which
makes it even more performant.

Ok, 1) and 2) are valid reasons from your point of view and that’s fair
enough. However, those should be of no concern when it comes to spec’ing a
new language as they’re implementation details of the Lucee server at this
point.

If custom tags are slower now, that’d need be looked into and I’m sure
there’ll be a way for better caching in a revised implementation of custom
tags, too. Essentially, saying components are better/preferred because of
the reasons mentioned is imho as bad as premature optimisation of code.

it keeps all of my rendering code in a single file, so it’s much
easier to find the piece I’m looking for when I need to do so.

Playing devil’s advocate I could now say: Ok, let’s put everything for a
page into one file, much easier to find stuff then, right?

Obviously it’s not that easy, but I personally think using an UIRenderer
component with functions to create HTML is good architectural practice. I
strongly think it’s the other extreme of putting business logic into your
cfml page template. If you chose to do that, that’s your option, but a new
language shouldn’t endorse that at all but instead opt for a clear
separation between what the respective components of the language are good
at.

Cheers
Kai

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/A08CB133-72E9-4B3C-8F9B-4CE4633EEC8F%40gmail.com
.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEBzVDffcoPPv8cvvtQRMHRSPOfVcNXhXT%2BzZDDzRC3eQfQ%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEBzVDffcoPPv8cvvtQRMHRSPOfVcNXhXT%2BzZDDzRC3eQfQ%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

micstriit · February 13, 2015, 9:22am

the attribute output is only really necessary with tag based components,
then only they produce output “on their own”.
script based code only producing output when you do a echo(…), so why
suppress your own actions by default?

MichaOn Fri, Feb 13, 2015 at 10:18 AM, Dominic Watson <@Dominic_Watson wrote:

If that were a .lucee.cfc (or whatever), I’d like to see that output=false
would be default. I would strongly discourage that kind of use of a CFC
function and be pleased if the language to a lead in doing so too. i.e. why
have the function output anything when it can return the value:

component {
public string function markdownTitleAndDescription( required string
title, required string description ) output=false {
return “##” & title & "##
" & description;
}
}

…

#markdownHelper.markdownTitleAndDescription( ‘title’, ‘lorem ipsum…’ )#

–
Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAEYvUx%3Ddj3g1txWR0AA-YT68ms%3D6xA9XpUXT%2BD%3DDmknXfyqqKQ%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAEYvUx%3Ddj3g1txWR0AA-YT68ms%3D6xA9XpUXT%2BD%3DDmknXfyqqKQ%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

Kai_Koenig · February 13, 2015, 5:04am

Option 2)
Don’t have a UIRenderer component but have tag-based custom tags for rendering your widget (lists) or pagination etc. THAT is what tag-based custom tags are really good at and useful for. Then on your page it’d actually uses the custom tags which probably fits nicely into whatever layout templating or page wrapper setup you prefer.

Personally, I think option 2 is much to be preferred as it separates rendering (tag based in custom tags or templates) from business logic (script based in components) very nicely.
right. that’s the way I used to do it before components were introduced
into the language. but

it proved to be much slower to begin with.

by using functions I can use cachedWithin, so for example, if I pass
a widgetId and the function has to do a lookup to get more details (like
name, price, etc), this can all be cached by Lucee internally, which
makes it even more performant.

Ok, 1) and 2) are valid reasons from your point of view and that’s fair enough. However, those should be of no concern when it comes to spec’ing a new language as they’re implementation details of the Lucee server at this point.

If custom tags are slower now, that’d need be looked into and I’m sure there’ll be a way for better caching in a revised implementation of custom tags, too. Essentially, saying components are better/preferred because of the reasons mentioned is imho as bad as premature optimisation of code.

it keeps all of my rendering code in a single file, so it’s much
easier to find the piece I’m looking for when I need to do so.

Playing devil’s advocate I could now say: Ok, let’s put everything for a page into one file, much easier to find stuff then, right?

Obviously it’s not that easy, but I personally think using an UIRenderer component with functions to create HTML is good architectural practice. I strongly think it’s the other extreme of putting business logic into your cfml page template. If you chose to do that, that’s your option, but a new language shouldn’t endorse that at all but instead opt for a clear separation between what the respective components of the language are good at.

Cheers
Kai

Abram_Adams · February 13, 2015, 6:23am

I use tags in less than 1% of the components that I write – in most cases
it’s just that one component that does the rendering.

Then let’s focus on creating a platform that is awesome at the other 99%.
Making quality compromises for the 1% edge case, which is arguably poor
design to begin with regardless of the claim that it was borne out of
performance issues is not a way to design a new language. CFML has plenty
of those poorly decided “features” already and if someone wants to make use
of those then they can still do it in legacy tagged base cfc, but for a new
dialect, specifically .lucee I think it would be a bad call.

I’ve developed many sites (e-commerce and otherwise) that require
thumbnails, reusable html blocks, etc… and I have never, ever had issues
with using custom tags as a solution. Granted, most of that was with ACF,
so perhaps Railo/Lucee has an issue and just needs a better custom tag
implementation?

Consider the following alternatives to your functions:
<widget:thumbnail size=“small” id=“#widgetId#”/>
<widget:thumbnail size=“large” id=“#widgetId#”/>
<widget:pagination pagesize=“20” pagenumber=“1” baseurl=“…”/>

Doesn’t that provide better reusability? Just reduced your 3 functions
into 2 very expressive and intuitive tags that naturally fit in your HTML.
Now pretend you’re a non-developer-designer that is styling the widget
listing page you just made. Would the following be very intuitive:

... oUIR = new UIRenderer();

for (var widgetId in searchResults) 
    oUIR.renderSmallWidgetThumbnail(widgetId);

other content...

Let’s not let the 1% use case dictate the direction the language goes.
Please.On Thursday, February 12, 2015 at 6:38:12 PM UTC-8, Igal wrote:

just to be clear:

I use tags in less than 1% of the components that I write – in most
cases it’s just that one component that does the rendering.

that doesn’t mean, however, that it is not an important feature of the
language.

the bottom line, as far as I’m concerned, is that “tag islands” in
script would be a great feature.

On 2/12/2015 5:49 PM, Igal @ Lucee.org wrote:

Option 2)
Don’t have a UIRenderer component but have tag-based custom tags for
rendering your widget (lists) or pagination etc. THAT is what tag-based
custom tags are really good at and useful for. Then on your page it’d
actually uses the custom tags which probably fits nicely into whatever
layout templating or page wrapper setup you prefer.

Personally, I think option 2 is much to be preferred as it separates
rendering (tag based in custom tags or templates) from business logic
(script based in components) very nicely.
right. that’s the way I used to do it before components were introduced
into the language. but

it proved to be much slower to begin with.

by using functions I can use cachedWithin, so for example, if I pass
a widgetId and the function has to do a lookup to get more details (like
name, price, etc), this can all be cached by Lucee internally, which
makes it even more performant.

it keeps all of my rendering code in a single file, so it’s much
easier to find the piece I’m looking for when I need to do so.

On 2/12/2015 5:39 PM, Kai Koenig wrote:

the main difference between you (plural) and I is that you try to
push me to do things your way, while I prefer to keep my options open
I would strongly debate that, but that’s a different discussion.

Kai – the fact that you don’t understand something doesn’t make it
bullsht. I’ve always treated you with respect – it’d be nice if you’d
try to do the same
Just to make things clear - the bullisht comment was not targeting you
in particular but anyone in this discussion trying to convince me of
breaking away from common-sense separation of concerns architectural
principles without providing a use case why their proposed solution is
better.

Now you HAVE supplied such a case (see below) and we can discuss your
argument. That has nothing to do with not understanding something at all.

I will try to show an example of what I mean, hopefully the
oversimplification will not make it miss the point
a) I don’t see how the approach below differs from what Abram’s said:

"So, what would stop you from just including a cfm file with your UI
stuff if you want it inside a cfc? To me that is the cleaner approach.”

To me, that’d be a much clearer approach, too, instead of sticking
markup into a component. If you really wanted to have a UIRenderer
component.

b) Let’s assume you did NOT have tags in components, how would this
requirement be solved nicely?

Option 1)
Script component including a tag/markup file. That’s essentially the
CFML-based version of a mixin (well, -ish) and I don’t think there’s
anything wrong with that.

Option 2)
Don’t have a UIRenderer component but have tag-based custom tags for
rendering your widget (lists) or pagination etc. THAT is what tag-based
custom tags are really good at and useful for. Then on your page it’d
actually uses the custom tags which probably fits nicely into whatever
layout templating or page wrapper setup you prefer.

Personally, I think option 2 is much to be preferred as it separates
rendering (tag based in custom tags or templates) from business logic
(script based in components) very nicely.

Cheers
Kai

Kai_Koenig · February 13, 2015, 12:37am

So, what would stop you from just including a cfm file with your UI stuff if you want it inside a cfc? To me that is the cleaner approach.
this is like asking “why do we need functions or custom tags in the language when we can just write the function’s body into a snippet and use cfinclude…”

there are times when you want to include a snippet/template, there are times when you want to use custom tags, and there are times when you want to use functions.

Two notes:

Funny, in another thread I was told by Micha that tag-based custom tags are bad and should not exist — that we all should use component-based custom tags because it’s all about the simplification and cleanup of the language…
Unless someone finally provides a realistic and non-abstract (“there are times when…”) appropriate use case of using tags over script in a component, I will continue to call bullsh*t on people who suggest that’d be a good idea in language design in this or any other parallel universe.

Cheers
Kai

Adam_Cameron1 · February 13, 2015, 1:16am

the main difference between you (plural) and I is that you try to
push me to do things your way, while I prefer to keep my options open.

Oh fuck off Igal.

I assure you that is not the chief difference between you (singular) and
myself and Kai. However it would be “indelicate” of me to point out what
is the chief difference.

so you create a Renderer component where you put some of your rendering
functions (the ones that apply to multiple pages, like so:
<cffunction name="renderSmallWidgetThumbnail">
    <cfargument name="widgetId">

    
</cffuntion>
then on each page that uses those you can instantiate the component and
call the functions, for example, on pages that show items thumbnails, you
do:

You’ve demonstrated at least Abram’s point with your own blimin’ example!
You’ve gone and factored-out all the mark-up! Why’s that? Because it’s a
different concern than the code.

Having a comment which amounts to “mark-up goes here” is the equivalent of
sticking it in an include, which also basically says “mark-up [will go]
here”.On 13 February 2015 at 01:01, Igal @ Lucee.org <@Igal> wrote:

–
Adam

Igal · February 13, 2015, 5:31am

Playing devil’s advocate I could now say: Ok, let’s put everything for a page into one file, much easier to find stuff then, right?
at an extreme, sure, but I’m talking only about reusable snippets here.

I just checked on one e-commerce site and I have there a UIRenderer with
17 functions and about 400 SLOC, so it’s far from getting out of hand.

Igal Sapir
Lucee Core Developer
Lucee.org http://lucee.org/On 2/12/2015 9:04 PM, Kai Koenig wrote:

Option 2)
Don’t have a UIRenderer component but have tag-based custom tags for rendering your widget (lists) or pagination etc. THAT is what tag-based custom tags are really good at and useful for. Then on your page it’d actually uses the custom tags which probably fits nicely into whatever layout templating or page wrapper setup you prefer.

Personally, I think option 2 is much to be preferred as it separates rendering (tag based in custom tags or templates) from business logic (script based in components) very nicely.
right. that’s the way I used to do it before components were introduced
into the language. but

it proved to be much slower to begin with.

by using functions I can use cachedWithin, so for example, if I pass
a widgetId and the function has to do a lookup to get more details (like
name, price, etc), this can all be cached by Lucee internally, which
makes it even more performant.
Ok, 1) and 2) are valid reasons from your point of view and that’s fair enough. However, those should be of no concern when it comes to spec’ing a new language as they’re implementation details of the Lucee server at this point.

If custom tags are slower now, that’d need be looked into and I’m sure there’ll be a way for better caching in a revised implementation of custom tags, too. Essentially, saying components are better/preferred because of the reasons mentioned is imho as bad as premature optimisation of code.

it keeps all of my rendering code in a single file, so it’s much
easier to find the piece I’m looking for when I need to do so.
Playing devil’s advocate I could now say: Ok, let’s put everything for a page into one file, much easier to find stuff then, right?

Obviously it’s not that easy, but I personally think using an UIRenderer component with functions to create HTML is good architectural practice. I strongly think it’s the other extreme of putting business logic into your cfml page template. If you chose to do that, that’s your option, but a new language shouldn’t endorse that at all but instead opt for a clear separation between what the respective components of the language are good at.

Cheers
Kai

Kai_Koenig · February 13, 2015, 1:39am

the main difference between you (plural) and I is that you try to push me to do things your way, while I prefer to keep my options open

I would strongly debate that, but that’s a different discussion.

Kai – the fact that you don’t understand something doesn’t make it bullsh*t. I’ve always treated you with respect – it’d be nice if you’d try to do the same

Just to make things clear - the bullish*t comment was not targeting you in particular but anyone in this discussion trying to convince me of breaking away from common-sense separation of concerns architectural principles without providing a use case why their proposed solution is better.

Now you HAVE supplied such a case (see below) and we can discuss your argument. That has nothing to do with not understanding something at all.

I will try to show an example of what I mean, hopefully the oversimplification will not make it miss the point

a) I don’t see how the approach below differs from what Abram’s said:

"So, what would stop you from just including a cfm file with your UI stuff if you want it inside a cfc? To me that is the cleaner approach.”

To me, that’d be a much clearer approach, too, instead of sticking markup into a component. If you really wanted to have a UIRenderer component.

b) Let’s assume you did NOT have tags in components, how would this requirement be solved nicely?

Option 1)
Script component including a tag/markup file. That’s essentially the CFML-based version of a mixin (well, -ish) and I don’t think there’s anything wrong with that.

Option 2)
Don’t have a UIRenderer component but have tag-based custom tags for rendering your widget (lists) or pagination etc. THAT is what tag-based custom tags are really good at and useful for. Then on your page it’d actually uses the custom tags which probably fits nicely into whatever layout templating or page wrapper setup you prefer.

Personally, I think option 2 is much to be preferred as it separates rendering (tag based in custom tags or templates) from business logic (script based in components) very nicely.

Cheers
Kai

Adam_Cameron1 · February 13, 2015, 1:53pm

If that were a .lucee.cfc (or whatever), I’d like to see that output=false
would be default. I would strongly discourage that kind of use of a CFC
function and be pleased if the language to a lead in doing so too. i.e. why
have the function output anything when it can return the value:

component {
public string function markdownTitleAndDescription( required string
title, required string description ) output=false {
return “##” & title & "##
" & description;
}
}

…

#markdownHelper.markdownTitleAndDescription( ‘title’, ‘lorem ipsum…’ )#

Agreed.

And Micha, using poor coding to demonstrate something doesn’t do anything
to cement your position.On 13 February 2015 at 22:18, Dominic Watson <@Dominic_Watson> wrote:

–
Adam

Adam_Cameron1 · February 13, 2015, 5:21am

it proved to be much slower to begin with.

by using functions I can use cachedWithin, so for example, if I pass
a widgetId and the function has to do a lookup to get more details (like
name, price, etc), this can all be cached by Lucee internally, which
makes it even more performant.

Ok, 1) and 2) are valid reasons from your point of view and that’s fair
enough. However, those should be of no concern when it comes to spec’ing a
new language as they’re implementation details of the Lucee server at this
point.

If custom tags are slower now, that’d need be looked into and I’m sure
there’ll be a way for better caching in a revised implementation of custom
tags, too. Essentially, saying components are better/preferred because of
the reasons mentioned is imho as bad as premature optimisation of code.

it keeps all of my rendering code in a single file, so it’s much
easier to find the piece I’m looking for when I need to do so.

Playing devil’s advocate I could now say: Ok, let’s put everything for a
page into one file, much easier to find stuff then, right?

That’s a bit reductio ad absurdum, but I think it does give one pause to
think about whether Igal’s approach is a great way to organise code in the
first place. It’s kinda trying to make objects and methods out of code
which isn’t a great fit for it.

Obviously this is all opinion, and there’s nothing wrong with that when
taking application implementation approach into consideration. However it’s
not making a case for Lucee being implemented specifically to cater for
approaches like this.

Obviously it’s not that easy, but I personally think using an UIRenderer
component with functions to create HTML is good architectural practice. I
strongly think it’s the other extreme of putting business logic into your
cfml page template. If you chose to do that, that’s your option, but a new
language shouldn’t endorse that at all but instead opt for a clear
separation between what the respective components of the language are good
at.

Nicely put, Kai.

If someone wants to do view processing in their CFC methods, they can with
string concatenation. There’s no need to encourage that approach by
creating special syntax for it.On 13 February 2015 at 18:04, Kai Koenig <@Kai_Koenig> wrote:

–
Adam

Alternative templating schemes

– Adam

– Adam

–
Adam

–
Adam