Alternative templating schemes

[Igal]

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

1. it proved to be much slower to begin with.

2. 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.

3. 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:

1. 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.

2. 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.

3. 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

[michael_zock]

2. supporting tag islands in script

This was something I pushed for on the CFML Advisory Committee and I still
think is a good idea, if we can agree on a nice syntax for it. I’d be OK
with {{: … :}} but I’d like to see some other suggestions.

Glad I’m not the only one who’d prefer the advantage of something like that!
There are situations where it will result in cleaner code if a view helper
simply uses with tags inside instead having to use manual
string concatenation or a string builder…On Thursday, February 12, 2015 at 10:06:41 PM UTC+1, Sean Corfield wrote:

On Feb 12, 2015, at 12:56 PM, Michael Offner <mic...@lucee.org <javascript:>> wrote:

[Igal]

comments in text:

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…
trycf is impressive. well done.

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?
no, I actually started that with ACF. ACF’s performance is even worse.

Consider the following alternatives to your functions:
|
widget:thumbnailsize=“small"id=”#widgetId#"/
<widget:thumbnailsize=“large” id=“#widgetId#”/>
<widget:paginationpagesize=“20” pagenumber=“1” baseurl=“…”/>
|

Doesn’t that provide better reusability?
not in my opinion. it is also much more work to maintain the code in
all the different custom tags. add to that the performance difference
and it’s a no-go for me.

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...

#oUIR.renderPagination(...)# |

Or do you think this would be clearer:
|

...

other content...

|

you’re taking some of the things I wrote and added much of your own
assumptions.

Let’s not let the 1% use case dictate the direction the language goes.
Please.
my point was that even though it might be just 1%, it is still very
important and adds a lot.

I don’t understand why the insistence to remove features that you guys
don’t like. if you don’t want to use them, don’t use them. it doesn’t
mean that no one should use them.On 2/12/2015 10:23 PM, Abram Adams wrote:

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
>
> 1) it proved to be much slower to begin with.
>
> 2) 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.
>
> 3) 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:
>>> 1) 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.
>>
>>> 2) 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.
>>
>>> 3) 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
>>
>>
>>

–
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/47d84ac6-4b54-4a9d-be55-79fde7a61689%40googlegroups.com
https://groups.google.com/d/msgid/lucee/47d84ac6-4b54-4a9d-be55-79fde7a61689%40googlegroups.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout.

[Igal]

I would prefer something like

<< ... content goes here ... >>

    or

<<<  ... content goes here ... >>>

it makes more sense to me since it’s the angular brackets that denote tags.

Igal Sapir
Lucee Core Developer
Lucee.org http://lucee.org/On 2/12/2015 1:06 PM, Sean Corfield wrote:

On Feb 12, 2015, at 12:56 PM, Michael Offner <@Michael_Offner> wrote:

2. supporting tag islands in script
   This was something I pushed for on the CFML Advisory Committee and I still think is a good idea, if we can agree on a nice syntax for it. I’d be OK with {{: … :}} but I’d like to see some other suggestions.

In my opinion we need no prefix for tags, so simply

#now()# <!— no output necessary! —>
<!— attribute values with no " are handled as expression, not strings! —>

<!— ignored and outputed as it is —>

the tags Lucee does not know are simply ignored then.
Fair enough. I like some prefix just because it makes it easier to find “code” in amongst the markup.

Sean Corfield – (904) 302-SEAN
An Architect’s View – http://corfield.org/

“Perfection is the enemy of the good.”
– Gustave Flaubert, French realist novelist (1821-1880)

[Igal]

1. 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.

2. 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.

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

say that you have an e-commerce site where on different pages (catalog,
search results, similar items, purchase history, etc) you display the
widgets’ thumbnails with basic information like name, price, etc.

you also use on different types of pages pagination links, and other
elements that the site requires.

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">

    <!--- code goes here to render html with thumbnail, name, price,

etc !—>

<cffunction name="renderLargeWidgetThumbnail">
    <cfargument name="widgetId">

    <!--- code goes here to render html with thumbnail, name, price,

etc !—>

<cffunction name="renderPagination">
    <cfargument name="baseUrl">
    <cfargument name="pageNumber" default="1">
    <cfargument name="pageSize" default="20">

    <!--- render links for pages 1 .. N or whatever !--->
</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:

oUIR = new UIRenderer();

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

then at the bottom of the page, you can easily add pagination by calling
oUIR.renderPagination(…)

what exactly is wrong with this example, and how would you make it
better without the tags?

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

On 13 February 2015 at 00:32, Igal @ Lucee.org http://Lucee.org <@Igal mailto:Igal> 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..."

No Igal, actually your position is more like that. Rolling
disparate pieces of code into one location, instead of separating it out.

Fully agreeing with Adam (btw: awesome to have you in my timezone for
a change — helps immediate responses)

–
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/F9D3D894-A4FC-48B8-B5EA-8C63C597426B%40gmail.com
https://groups.google.com/d/msgid/lucee/F9D3D894-A4FC-48B8-B5EA-8C63C597426B%40gmail.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout.

[Dominic_Watson]

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

[micstriit]

see my comments between the lines

Micha

1. 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.

2. 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.

3. 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!On Fri, Feb 13, 2015 at 2:39 AM, Kai Koenig <@Kai_Koenig> wrote:

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.

[Dave_Merrill]

2. 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.

My original post on this included several specific examples:

build an html select from a query and select the option with a specified
value, build a set of radios from the same data

I’m sure you can think of many more – they’re probably in your collection
of custom tags… Because that’s what you do with common code, put it
somewhere it can be reused (like in a method of a base class maybe?).

Yes you could include a tag-based cfm with those functions, but that seems
more tortured and less cohesive to me than writing a perfectly legal
tag-based CFC.

Just because you don’t choose to write your code this way doesn’t make it
wrong.On Thursday, February 12, 2015 at 7:37:32 PM UTC-5, Kai Koenig wrote:

[Dave_Merrill]

This. My original post included some examples:

build an html select from a query and select the option with a specified
value, build a set of radios from the same data…, higher level UI
widgets, etc

I assume nobody’s duplicating the code for such things, right? So why not
have methods for them in a renderer base class, like you would for common
methods in a model or controller?

There’s also the usual inheritance benefits – this view is just like the
other one only with some extra stuff, so it can extend the other one, or
both can extend a common base.

I really don’t get why this is SO controversial. What is so special about
view rendering code that principles and strategies that apply to models and
controllers don’t apply? What’s so sacred about CFMs for rendering? If you
don’t like that approach, don’t use it, but don’t assume that everyone
agrees and remove it from the language.On Thursday, February 12, 2015 at 5:25:29 PM UTC-5, 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.

[Adam_Cameron1]

Of course cfm templates cannot be inside a component mapping, so this
makes it very hard to link them with components.

Can you pls expand on what you mean here?On Friday, 13 February 2015 21:17:46 UTC+13, Micha wrote:
–
Adam