Alternative templating schemes

[Dan Skaggs]

In another thread (An Outsider's Perspective) there has been a bunch of talk of changes to Lucee to make it seem less like CFML and appeal to the "wider audience".

One thing I'd like to see is we allow the view files to use Handlebars syntax in view files as an alternative to #variableName#, cfloop, cfoutput, etc. You'd no longer need cfoutput since {{variableName}} would automatically be translated.

It also removes a visual link to the CFML past. Obviously we'd need to keep the current parser in place or we'd break every CFML app people tried to bring to Lucee. I have no idea how difficult this would be for the parser to support but I personally like the idea of having a very similar paradigm to the JS that we all are increasingly writing.

Food for thought (hopefully).

Dan

[Adam Cameron]

Yup. good idea.

Having moved off CFML for views (we're using Twig now), I actually find CFML tags a bit clunky to look at; with their endless repetition of CF-this and CF-that, and general verbosity.

Also - as you say - if they're moving away from being identified with CFML, the "<cf" has to go.

I'd recommend picking the most popular templating system and using a flavour of that instead.

Nice one, Dan.

-- 

Adam

Dan

--
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/99798043-B60D-4DF7-A327-94F64A9598A3%40web-meister.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Drew]

Just a suggestion, whatever templating language is chosen for Lucee files, can we use a character that is obvious on both Mac and PC keyboards?

(No Mac vs PC war here pls) On Mac, the # is Alt+3 which is annoying for newbies (I have muscle memory now) so { or [[ or whatever is cool 

But not keys like ¡ € # ¢ ∞ § ¶ • ª or º ok?

Regards

Mark Drew

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFwR%2BKfy9p%3DKz8g1Fed0fvyqVLLiDBRZ7aPcB52zZ1BttEn_qg%40mail.gmail.com.

[Jonas Hauß]

How about Mustache.js in Lucee?
Simple syntax and very easy to use!

[Dan Skaggs]

Yeah that's kinda what I had in mind but I mentioned Handlebars as my example because that's the one I'm familiar with. From what I understand Mustache and Handlebars are very similar.

On Feb 6, 2015, at 1:28 PM, Jonas Hauß <hauss...@gmail.com> wrote:

How about Mustache.js in Lucee?
Simple syntax and very easy to use!

--
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/3906b56f-bf31-4e1b-91f8-19e219a870c3%40googlegroups.com.

[Mark Drew]

Or do as express.js does and leave the rendering engine up to you. So add an extension for moustache or handlebars and just do

This.renderer="moustache";

Mark Drew

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CC2A1C6D-6C64-439D-B8B1-24D88CC44A73%40web-meister.com.

[Ryan Guill]

If we are going this route I would prefer the ability to choose a rendering engine, but would rather not have to specify which one to use at an application level - I can imagine scenarios where one might want to mix and match.

[Jonas Hauß]

this.renderer is an awesome idea!
This gives everyone the ability to choose implemented renderers or create custom ones. Would be pretty neat.

[Michael Offner]

Please do not forget that different countries have different keyboard layouts.

So we should optimize it for the Swiss German keyboard! 

;-)

Micha

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/541A189C-9B57-4B51-BFAD-ED71490F966E%40gmail.com.

[Abram Adams]

I agree on the moving from CF stigmas, but I think we should be careful on what we throw out with the bathwater.

For instance, if we make the templating syntax the same as handlebars or mustache or all the other double-curly template engines, it further blurs the line between what is server side and what is client side and could easily cause collisions. Many times I want to serve a fully server-side rendered page that has client-side templating embedded in the html so that it can dynamically re-render when state changes client-side. If Lucee automatically parsed the double curlies it could bring unexpected results like throwing server side errors.

I personally think the templating syntax for cfml is actually really good if used responsibly. Using tags to control basic logic and #'s to evaluate code is a very natural fit inside html.

my $0.02

[Adam Cameron]

On 7 February 2015 at 18:35, Abram Adams <cfxc...@gmail.com> wrote:

For instance, if we make the templating syntax the same as handlebars or mustache or all the other double-curly template engines, it further blurs the line between what is server side and what is client side and could easily cause collisions.  Many times I want to serve a fully server-side rendered page that has client-side templating embedded in the html so that it can dynamically re-render when state changes client-side.  If Lucee automatically parsed the double curlies it could bring unexpected results like throwing server side errors.  

I see it like client-side JS vs server-side JS. People seem to cope with that OK.

I reckon using the "best" or most-popular (according to today's zeitgeist) client-side view-template engine for doing the server-side templating as a *reduction* in barrier-to-entry.

 

my $0.02

Your opinion is worth more than that, mate. Don't sell yourself short.

My 500 quid.

-- 

Adam

[Jean Moniatte]

On Sat, Feb 7, 2015 at 7:47 PM, Abram Adams <cfxc...@gmail.com> wrote:

I personally think the templating syntax for cfml is actually really good if used responsibly.  Using tags to control basic logic and #'s to evaluate code is a very natural fit inside html.

I agree, I do not see a need for change here. CFML is really good for view templates.

Thanks,

Jean

--

Jean Moniatte

UGAL

je...@ugal.com

http://www.ugal.com

[Abram Adams]

so given the following pseudo code (assuming js templating is wired up):

<script>

var someVar = "abc";

</script>

<cfscript>

someVar = "def";

</cfscript>

<div>

{{someVar}} {{someVar}}

</div>

What would the the output be?

[Sean Corfield]

On Feb 7, 2015, at 11:37 AM, Jean Moniatte <je...@ugal.com> wrote:

On Sat, Feb 7, 2015 at 7:47 PM, Abram Adams <cfxc...@gmail.com> wrote:

I personally think the templating syntax for cfml is actually really good if used responsibly.  Using tags to control basic logic and #'s to evaluate code is a very natural fit inside html.

I agree, I do not see a need for change here. CFML is really good for view templates.

I also agree but I would like to see the _amount_ of logic restricted in view templates so perhaps a <lc:tagname …> … </lc:tagname> syntax but with only a small subset of tags actually available? Maybe just:

* <lc:if>

* <lc:switch>

* <lc:loop>

* <lc:script> - if you really must embed logic, at least make it script!

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)

[Adam Cameron]

Don't get me wrong, I am not suggesting that Lucee should be generating anything that runs on the client, I just mean using the same syntax.

So instead of having something like:

<ul>

<cfoutput query="users">

 <li>#name#</li>

</cfoutput>

</ul>

one would have:

<ul>

{% for user in users %}

    <li>{{ user.name }}</li>

{% endfor %}

</ul>

(that's using Twig syntax, purely because it's what I use @ work in PHP, and it was the easiest to knock together)

I'm not advocating using Twig for server-side templating, I'm advocating using the same dialect of [whatever's most popular at the moment]. But still on the server.

The benefit being that ppl how are used to doing it clientside will be au fait with it server side too. And, indeed, in mixed-responsibility environments (client- & server-side templating both), the files can be reused.

The main point is that there are a number of fairly similar templating systems out there which ppl are familiar with. And then there's CFML code. Which most people are not familiar with. There's no need to persist with the CFML style of doing views if we're not hanging on to CFML.

-- 

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/81cfeb20-523d-48cc-bab4-8c3be123cd00%40googlegroups.com.

[Jean Moniatte]

And the ability to call built-in and user defined functions as well ? 

--
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/DD6264EC-BAD7-4032-ADEA-DDBCBA1FF470%40corfield.org.

[Adam Cameron]

On Sat, Feb 7, 2015 at 8:53 PM, Sean Corfield <se...@corfield.org> wrote:

I also agree but I would like to see the _amount_ of logic restricted in view templates so perhaps a <lc:tagname …> … </lc:tagname> syntax but with only a small subset of tags actually available? Maybe just:

* <lc:if>

* <lc:switch>

* <lc:loop>

Yup.

 

* <lc:script> - if you really must embed logic, at least make it script!

I'd say custom tag for that. Or just not allow it, because if you needed it, you're doing it wrong. Don't do it wrong.

On 7 February 2015 at 20:17, Jean Moniatte <je...@ugal.com> wrote:

And the ability to call built-in and user defined functions as well ? 

Formatting-for-output functions, yes.

And methods on objects. Ones that return something to be iterated over, or strings to be output.

But the bulk of CFML's functionality simply does not belong in views. 

-- 

Adam

[Michael Offner]

2 things are very important for me:

1. it should be about loosing weight not get a other person, we should keep what makes cf unique and good, only ditch the bullshit.

2. The application.cfc is like a mini framework and I was asking myself a lot in the past, should we go further with that concept. But I don't think so today, we have great framworks like fw/1 and coldbox that do a great job in that sector, so add any further framework logic to the language only limits the possibilities.

Micha

--

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%2BKeWA-4D0STM1-W3GURNj4%2Bm8FUv5HcJ8-n%2BW3pSreV5%3DA%40mail.gmail.com.

[Ryan Guill]

> I'd say custom tag for that. Or just not allow it, because if you needed it, you're doing it wrong. Don't do it wrong.

thats just like, your opinion man. And I think its important to point this out because there are some people who take what you say as having weight and authority here.  Sure, there are lots of reason for good separation of concerns in application development, even reasons to encourage that from a language standpoint.  But there are other people who will disagree for good reason.  Take a look at react for an example of mixing logic and view. Please remember that there are people who need to write simple scripts, not applications - and that may mean a one page chunk of logic and view. Please, in general, remember that there are people who have needs and tastes that don't match your own.

I'm not against supporting other template engines, especially if it makes someone coming from other languages more comfortable, but I don't see any point in getting rid of pound signs and cfml just because you think its old and crufty.  Give people options, don't restrict based on some high-horse idea of right and wrong. Lets extend the language, give new options.  Make the case why the new way is the best way and let developers convert as they are convinced, not take away their toys and tell them they're playing with them wrong.

I would still argue that lucee's long term success comes from converting devs from ACF (including those who you think killed CFML because they had the audacity to use features they were given).  Maybe lucee 5 will prove me wrong, but I just don't see lucee appealing to people outside of the existing CFML community, no matter how much you try to distance yourself from its CFML past.  Perhaps we can broaden appeal with new .lucee files that have modern, "strict mode" features, but if you eschew the CFML that brought you, who is lucee going to appeal to? Why should I pick lucee over even any of the other JVM languages that set out with clear goals and modern features from the outset? I'm here because of two reasons - my employer(s) and I have a large amount of existing code we would like to continue to support; and I have 15+ years of experience writing CFML.  I can completely understand the desire to move in a new direction and get rid of the past, but I would have literally no reason to stick around. Perhaps i'm the only one like this, I suspect i'm not.

I'd like to also propose that for large feature proposals like this that we take a page from JS, Python, Java and other languages and actually put forward actual formal proposals.  Here is an example from python: https://www.python.org/dev/peps/pep-0255/, or another from JS: https://github.com/tc39/Array.prototype.includes/  This would allow us to discuss and refine ideas, allow the lucee team to accept proposals but say that certain parts need tweeks or more thought. It would also make it clear to outsiders exactly what status a given proposal is in, and if it has the approval of the team or not.  I would argue both the google group and the bitbucket issues are not ideal places for conversations like these, unless it is a simple new function or tweak.  I don't know all the answers on how to do it, but want to throw it out there for considerations.

My 2 cents.

[Raymond Camden]

I like this list as well, with <lc:if> being crucial. One of the biggest issues I have with Handlebars, and I love Handlebars, is that there is *zero* logic allowed, which is good in theory, but in practice, can be a pain the in the rear. Handlesbars has an IF, but only for one value, you can't do something like, if X=Y. 

When migrating a CF site to Node recently and using Handlebars, I had to write a custom function just to support this in CFML:

<option value="something" <cfif rc.category is "something">selected</cfif>>Something</option>

[Kai Koenig]

On Sat, Feb 7, 2015 at 7:47 PM, Abram Adams <cfxc...@gmail.com> wrote:

I personally think the templating syntax for cfml is actually really good if used responsibly.  Using tags to control basic logic and #'s to evaluate code is a very natural fit inside html.

I agree, I do not see a need for change here. CFML is really good for view templates.

+1, CFML is absolutely fine for view templates. There’s no need to jump on another syntax bandwagon for the templating purpose just because some _currently_ hip JS frameworks do certain things.

Cheers

Kai

[denstar]

On Sat, Feb 7, 2015 at 11:35 AM, Abram Adams wrote:

I agree on the moving from CF stigmas, but I think we should be careful on what we throw out with the dishwater.  

+1!

 

For instance, if we make the templating syntax the same as handlebars or mustache or all the other double-curly template engines, it further blurs the line between what is server side and what is client side and could easily cause collisions.  Many times I want to serve a fully server-side rendered page that has client-side templating embedded in the html so that it can dynamically re-render when state changes client-side.  If Lucee automatically parsed the double curlies it could bring unexpected results like throwing server side errors.  

Indubitably!  I like the idea of using extensions (cfmustache, cfhandlebars, etc.) vs. changing the standard.  

 

I personally think the templating syntax for cfml is actually really good if used responsibly.  Using tags to control basic logic and #'s to evaluate code is a very natural fit inside html.

Couldn't agree more!  I was a little bummed to see so much angst about tags in general.  They are just a way of giving context, and separating stuff, and you have to do that regardless of what you use.  JSON really needs schemas, for instance, but only the "big players" have realized that so far. 

-Den

[Julian Halliwell]

On 7 February 2015 at 18:47, Abram Adams <cfxc...@gmail.com> wrote:
> I personally think the templating syntax for cfml is actually really good if used responsibly. Using tags to control basic logic and #'s to evaluate code is a very natural fit inside html.

Views are one of the areas where I feel I can still hold my head high
as a CFML developer. I worked with a front-end designer recently and
after the usual raised eyebrow on learning the back-end was CF, he was
actually surprised at how easy my views were to deal with compared
with the Ruby he normally had to wrangle. The #s did trip him up a bit
given that they have meaning in HTML as anchors/ids and need escaping,
but the tag/attribute combination is very familiar (which was as the
Allaire bros intended it).

[Andrew Penhorwood]

On Saturday, February 7, 2015 at 3:38:42 PM UTC-5, Micha wrote:

2 things are very important for me:

1. it should be about loosing weight not get a other person, we should keep what makes cf unique and good, only ditch the bullshit.

2. The application.cfc is like a mini framework and I was asking myself a lot in the past, should we go further with that concept. But I don't think so today, we have great framworks like fw/1 and coldbox that do a great job in that sector, so add any further framework logic to the language only limits the possibilities.

Micha

Good because I have a framework written that works well with the current Application.cfc.  I already avoid all of the strange things Adobe added to the language over the years but unlike a lot of ColdFusion people I was a programmer before CF existed.  The only thing I have not jumped into is only coding in cfscript, mainly because my day job is as a ColdFusion developer on legacy applications.  That might change given we have someone sane developing the syntax.

Andrew Penhorwood

[Dave Merrill]

Plus a bunch for this Ryan.

If this is a whole new animal, with minimal relationship to and compatibility with CFML, what's the case for it vs the tons of already mature server-side languages? I get that some folks are exited about Lucee becoming a lab for their blue-sky vision of a new programming language, but why would anyone choose to use it unless they wanted to do those experiments too? They'd also have to believe their aspirations for it aligned with community consensus, and would in the future.

BOTTOM LINE: IMO it'd be a shame if Lucee becomes so radically different from CFML that my employer, my personal projects, and all other CFML apps and frameworks have to choose between this new language and CFML. Wouldn't surprise me if the answer in many cases would eventually be None Of The Above.

I don't mean to be overly dramatic, but is it really our intent to do away with open source CFML? To improve on every existing language, more or less from scratch?

Dave

[Adam Cameron]

On 8 February 2015 at 12:05, Dave Merrill <enig...@gmail.com> wrote:

Plus a bunch for this Ryan.

I'll get back to Ryan separately. :-|

 

I don't mean to be overly dramatic, but is it really our intent to do away with open source CFML? To improve on every existing language, more or less from scratch?

Did you miss the entire part of the conversation that any of this .lucee stuff is in addition to the existing and continued CFML support?

If your concern is the continuation of CFML support... a) there is no concern; b) I don't think this is the right thread to be voicing your (unwarranted) concerns.

-- 

Adam

[Adam Cameron]

On Saturday, 7 February 2015 20:56:05 UTC, Ryan Guill wrote:

> I'd say custom tag for that. Or just not allow it, because if you needed it, you're doing it wrong. Don't do it wrong.

thats just like, your opinion man.

Well... duh, Ryan. Of course it bloody is.

 

And I think its important to point this out because there are some people who take what you say as having weight and authority here.

Well they're bloody idiots then, TBH. And given that, then perhaps just doing what I say is perhaps better for them in the long run anyhow.

That said... I stand by what my opinion happens to be at the given point in time it as offered as being my best analysis of the situation, and accordingly my best advice. I seldom type stuff in for shits 'n' giggles.

I do reserve the right to change my opinion when presented with better information, though.

 

  Please remember that there are people who need to write simple scripts, not applications - and that may mean a one page chunk of logic and view. Please, in general, remember that there are people who have needs and tastes that don't match your own.

Right. So don't use a templating engine for that. Whenever a templating engine is in place, one can still just emit a string instead. No-one's forcing anyone to a framework (or a design pattern) for writing a simple script.

However the bulk of code written in CFML is not for simple scripts, it's not even for simple websites. It's for medium-to-complex websites (erring on the medium end of the scale, sure). And code written for that kind of requirement should be written "properly" (I don't think anyone here seriously disagrees with that?)

 

I'm not against supporting other template engines, especially if it makes someone coming from other languages more comfortable, but I don't see any point in getting rid of pound signs and cfml just because you think its old and crufty.

For fuck's fucking sake.

No-one is suggesting changing CFML *one jot*.

Jesus.

At no point has anyone suggested doing anything to Lucee's CFML support other than continuing it.

 

Give people options, don't restrict based on some high-horse idea of right and wrong. Lets extend the language, give new options.  Make the case why the new way is the best way and let developers convert as they are convinced, not take away their toys and tell them they're playing with them wrong.

I would still argue [...]

Well you're not arguing, you're just missing the point. 

 

I'd like to also propose that for large feature proposals like this that we take a page from JS, Python, Java and other languages and actually put forward actual formal proposals.  Here is an example from python: https://www.python.org/dev/peps/pep-0255/, or another from JS: https://github.com/tc39/Array.prototype.includes/  This would allow us to discuss and refine ideas, allow the lucee team to accept proposals but say that certain parts need tweeks or more thought. It would also make it clear to outsiders exactly what status a given proposal is in, and if it has the approval of the team or not.  I would argue both the google group and the bitbucket issues are not ideal places for conversations like these, unless it is a simple new function or tweak.  I don't know all the answers on how to do it, but want to throw it out there for considerations.

Yep, a very good suggestion. I think we're a wee ways off needing that sort of thing yet? I think the formal document should come after the initial general discussion. If we get some sort of accord on a given idea, then someone can draft up a formal proposal.

That said, I'll chat on a forum on stuff until the cows come home, but I'm buggered if I'd ever draft a formal proposal. Does that make me a bad person?

 

My 2 cents.

Stop diluting the merits of your contribution. Even if I don't agree with it ;-)

-- 

Adam

[Ryan Guill]

I'll admit, re-reading this thread, perhaps i've taken this conversation out of context.  I apologize.

> At no point has anyone suggested doing anything to Lucee's CFML support other than continuing it.

I disagree, but no point in arguing about it here.  If thats the case, then I retract my statements.

> Yep, a very good suggestion. I think we're a wee ways off needing that sort of thing yet? I think the formal document should come after the initial general discussion. If we get some sort of accord on a given idea, then someone can draft up a formal proposal. That said, I'll chat on a forum on stuff until the cows come home, but I'm buggered if I'd ever draft a formal proposal. Does that make me a bad person?

No, that't not what makes you a bad person ;)

I would say that now is exactly when we need that sort of thing.  I think theres a lot of talking circles around these features and it would be good to have them in a formal manner so that concerns with particular parts of a proposal can be debated clearly and contextually.  Instead of email replies that reply to multiple concerns at the same time and make it hard to track.

I think you already draft proposals all the time, here and on your blog - the only difference would be where you do it and maybe the formatting of it.  And it doesn't all have to come from one person.  But I think outlining what a proposal is, what the scope of it would be, what the impact would be and what it might look like would help direct these conversations. Sure, float the idea on the group to see if its worth putting a proposal together, but I think this this thread shows that there are lots of considerations and ideas to go along with something as simple as "a templating engine" that its worth structuring. Mostly though it feels like a lot of these conversations here are wasted cycles, with people being confused about different aspects (apparently me...) and good feedback being lost in the noise.

> Stop diluting the merits of your contribution. Even if I don't agree with it ;-)

I understand that my statements may be contentious and intend to present them with humility.  Its up to you to decide their merits.

--

Ryan

[Ryan Guill]

I think this is a good point Abram.  This is why <cfoutput> is useful in current CFML templates to designate the regions you intend to be interpolated.

I wonder how express.js handles this? I did some cursory googling but couldn't find anything.

[Adam Cameron]

On 8 February 2015 at 16:23, Ryan Guill <ryan...@gmail.com> wrote:

>> My 2 cents

> Stop diluting the merits of your contribution. Even if I don't agree with it ;-)

I understand that my statements may be contentious and intend to present them with humility.  Its up to you to decide their merits.

Appending "my 2 cents" / "my 2p" / etc is the humility equivalent of saying "you're a prick" and then appending a smiley face to it so you can say "but it was a joke" if called out on it.

It's trivial, but I think it's also slightly disingenuous.

-- 

Adam

NB: wasn't calling you a prick. That was just an example.

[Alex Skinner]

Well I think that's your interpretation of what it means.  I agree its an unnecessary ending but when I have added it I mean 'my thoughts for what they're worth'

A

Sent from my phone

--

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%2BKctmrsqC%2Bkm%2BG7DPaYsN53317nCj--vc_DqzFK_iraxMg%40mail.gmail.com.

[Adam Cameron]

Appending "my 2 cents" / "my 2p" / etc is the humility equivalent of saying "you're a prick" and then appending a smiley face to it so you can say "but it was a joke" if called out on it.

Sorry that could be taken the wrong way.

The parallel I was drawing was like with a Twitter message or something, when one says something a bit off, but then  adds an emoticon to make it all "OK".

-- 

Adam

[Ryan Guill]

That may be the way you take it, but thats not my intention.  I mean everything I say, but submit that its my opinion and that I understand that I may not be agreed with.  I don't mean it as a way of getting out of any of my statements.

[Adam Cameron]

On 8 February 2015 at 16:39, Alex Skinner <al...@pixl8.co.uk> wrote:

Well I think that's your interpretation of what it means.  I agree its an unnecessary ending but when I have added it I mean 'my thoughts for what they're worth'

Doesn't this go without saying though?

It's like when Ryan called me out saying "but that's just your opinion". Well... of course it is.

Anyway, let's not belabour it more than I already have. 

People should back themselves more, that's all I'm saying. Especially the likes of you & Ryan, who are pretty bloody clued-up. There's nothing wrong with being clued-up, and having a well-informed opinion!

-- 

Adam

[Mark Drew]

On 8 Feb 2015, at 16:25, Ryan Guill <ryan...@gmail.com> wrote:

I wonder how express.js handles this? I did some cursory googling but couldn't find anything.

In Express.js you set the rendering engine (what I mentioned before) 

such as 

app.set('view engine', 'ejs’);

Which means that when I get to render my view (or write to the response) I do :

res.render('tag/list', { tags: taglist, version: currentversion });

The first item being the ejs file I am going to use (/views/tag/list.ejs) and the object I am sending to it. It’s very FW/1 in that way. 

Hence I was suggesting that for liucee you could do (in Application.cfc) 

component {

this.renderingEngine(‘markdown’);

}

And you can then in the onRequest() just return 

function onRequest(){

return render(data);

}

of course this can just as happily be done in a framework. 

What I would prefer to see in Lucee though is being able to add dependencies so I can do (in Application.cfc):

this.dependencies: [

{markdown: “^1.0.2”}, 

{mongodb-lang: “3.0.2”}, 

{mongodb-cache: “2.0.2”}

]

and when the application starts, if the extensions aren’t there they are automagically installed. 

But one could hope eh?

MD 

[James Holmes]

On 9 February 2015 at 01:20, Adam Cameron <dac...@gmail.com> wrote:

this .lucee stuff is in addition to the existing and continued CFML support

On that point, the discussion seems to have been along the lines of "here's all the ruby features we want to pull in to lucee."

I'm going to re-ask the earlier question. "What's the case for it vs the tons of already mature server-side languages?"

[Kai Koenig]

On 9 February 2015 at 01:20, Adam Cameron <dac...@gmail.com> wrote:

this .lucee stuff is in addition to the existing and continued CFML support

On that point, the discussion seems to have been along the lines of "here's all the ruby features we want to pull in to lucee."

I'm going to re-ask the earlier question. "What's the case for it vs the tons of already mature server-side languages?”

+infinity

[Michael Offner]

I was planning to add support dependencies for the start script of the engine. 

Lucee start mongodb:1.2.3.4;

Supporting this in the application.lucee ( ;-) ) is raising some security questions for me. Technically it is no problem with lucee 5.

Micha

--
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/D27145D7-D7EA-4B0F-B089-91A13A6AF448%40gmail.com.

[Dave Merrill]

@Adam Cameron: It wasn't and isn't clear to me whether the templating changes proposed here are intended as additions, configurable options, or replacements for existing CFML constructs. Other proposals floating around -- for example doing away with the arguments scope, as proposed by Micha in another thread -- clearly aren't additions, they're breaking changes, so such things are clearly aren't off the table.

Point is that my compatibility concerns don't seem as "unwarranted" as you suggest. We as a community are of course free to make breaking changes in the interest of evolving the language, but it's also our responsibility to talk about how those changes would affect existing projects. Agreed that this thread isn't the main forum for such concerns, but compatibility rightly comes up in every context where changes are suggested, and all decisions about specific proposals need to address it.

[Adam Cameron]

I am 99% confident that all this discussion is completely separate from anything to do with Lucee's CFML support. Well that's the position I'm operating under, anyhow.

[Dan Skaggs]

My thought when starting the thread (and my apologies for not making this more clear dozens of messages ago), were to be able to "plug in" a new template scheme to override the current <cfoutput> and #variableName# scheme. However, after all the discussion, I'm of the opinion that this belongs solely in the "new Lucee language" and not as something that necessarily should be added to the current CFML support.

A couple of these threads have been long and winding and, while the discussion has been fun to follow, the ideas presented have not always been clearly marked as applying to current CFML support or the "new Lucee Language".

--
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%2BKdtP7zoKP1YCs3ik1iioGLoB0RZzd%3D2Eso_FC50ba5nNQ%40mail.gmail.com.

[Michael Offner]

People still will migrate existing apps, so compatibility is relevant to a certain point.

Micha

[Michael Offner]

I like the current scheme a lot, I only ask myself if we should get rid of <cfoutput> completely .

Maybe adding a <cfplain> instead that ignore all #.

Micha

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/2A49BB73-4921-431A-9A83-74D630F08DED%40web-meister.com.

[Gavin Pickin]

I like seeing all of this, its a good range of input.

I think the tag for views is fine.

<cfif> vs <lc:if> is a little strange, since it feels more custom tag like syntax… but least it would be an easy transition and it would be lc vs cf so we can distance ourselves.

I like the idea of having other rendering engines, as long as they were native fast… although we would definitely need to figure out a way to not complicate generation of handlebars templates etc

Like Abram said, I can definitely see some confusion happening.

As for scopes… CF 9 screwed up some of my code, because they changes the scope order for something… and it was hard to figure out.

I think VAR is cool, lets keep that… arguments is nice too, but if they were the same scope I’d be ok with that.

We can probably blow away the rest though.

If we got rid of any GOTCHA moments when teaching the language, it would be a good start finding the BS… most of them have already been mentioned.

Gavin Pickin

gpi...@gmail.com

http://www.gpickin.com

--
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/f5d7b045-fa86-41d3-8ba8-bd791189f409%40googlegroups.com.

[Jon Clausen]

Personally, I would prefer a short tag syntax for output and getting rid of <cfoutput> completely.  I find escaping #’s is a hassle and eliminating <cfoutput> without a short tag option would require it in all templates (or you would have to go back and add <cfplain>’s).  Escaping #’s also decreases portability of template code and creates hassles in refactoring or updating multiple templates via regex. 

<lc: myVar> (or <lc= myVar>, etc.), for example, could be the same as 

<cfoutput>

#myVar#

</cfoutput> 

or 

<cfscript>

writeOutput(myVar);

</cfscript> 

-Jon

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEByT8tuA%3D%2BszzffHn_vv7vhiA7Gu3zEa4hRV%2Bpap8G1DjQ%40mail.gmail.com.

[Dave Merrill]

There you go, an approach that doesn't break existing apps, I like it (<cfplain>).

[Mike Rankin]

Man I hate that embedded tag stuff.  It always wants to wreck my editor color coding.  I prefer:

<option value="something" #(rc.category is 'something') ? 'selected' : ''#>Something</option>

On Saturday, 7 February 2015 16:09:48 UTC-5, Raymond Camden wrote:

I like this list as well, with <lc:if> being crucial. One of the biggest issues I have with Handlebars, and I love Handlebars, is that there is *zero* logic allowed, which is good in theory, but in practice, can be a pain the in the rear. Handlesbars has an IF, but only for one value, you can't do something like, if X=Y. 

When migrating a CF site to Node recently and using Handlebars, I had to write a custom function just to support this in CFML:

<option value="something" <cfif rc.category is "something">selected</cfif>>Something</option>

On Saturday, February 7, 2015 at 1:53:09 PM UTC-6, Sean Corfield wrote:

On Feb 7, 2015, at 11:37 AM, Jean Moniatte <je...@ugal.com> wrote:

On Sat, Feb 7, 2015 at 7:47 PM, Abram Adams <cfxc...@gmail.com> wrote:

I personally think the templating syntax for cfml is actually really good if used responsibly.  Using tags to control basic logic and #'s to evaluate code is a very natural fit inside html.

I agree, I do not see a need for change here. CFML is really good for view templates.

I also agree but I would like to see the _amount_ of logic restricted in view templates so perhaps a <lc:tagname …> … </lc:tagname> syntax but with only a small subset of tags actually available? Maybe just:

* <lc:if>

* <lc:switch>

* <lc:loop>

[michae...@arcor.de]

On Tuesday, February 10, 2015 at 8:41:48 AM UTC+1, Micha wrote:

People still will migrate existing apps, so compatibility is relevant to a certain point.

Micha

Mostly in the same way you made Railo compatible to most of ACF code so people would have an easier upgrade path. 

[michae...@arcor.de]

On Saturday, February 7, 2015 at 8:53:09 PM UTC+1, Sean Corfield wrote:

On Feb 7, 2015, at 11:37 AM, Jean Moniatte <je...@ugal.com> wrote:

On Sat, Feb 7, 2015 at 7:47 PM, Abram Adams <cfxc...@gmail.com> wrote:

I personally think the templating syntax for cfml is actually really good if used responsibly.  Using tags to control basic logic and #'s to evaluate code is a very natural fit inside html.

I agree, I do not see a need for change here. CFML is really good for view templates.

I also agree but I would like to see the _amount_ of logic restricted in view templates so perhaps a <lc:tagname …> … </lc:tagname> syntax but with only a small subset of tags actually available? Maybe just:

* <lc:if>

* <lc:switch>

* <lc:loop>

* <lc:script> - if you really must embed logic, at least make it script!

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)

 

So, basically turn the CFML tags we'd want to keep into something similar to a JSP tag libary?

Reminds me that it might be useful to some people if Lucee could flexibly load the locations of actual ones similar to how you can already extend the class path in the Application.cfc (would cut down on the CFImport calls). Not sure if there's enough interest in that.

[Dave Merrill]

Just to throw it out there, I've sometimes built views as CFC components too, not CFM templates. The benefits are the same as in any other inheritance situation -- default behaviors with hierarchical override, access to common methods and "constants" (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). Yes you can use a tag library for common rendering functionality instead, or inject or instantiate another component that has it, but you can do that in model-land too, and nobody thinks that's a reason not to use CFCs there, the benefits of components and their inheritance tree are widely acknowledged.

My clear impression is that this isn't a popular strategy, having gotten shouted down on the Railo list for mentioning it, but I hope the .lucee world doesn't make design decisions assuming nobody will ever do that. Just to be clear, I haven't heard that said specifically, but these early days are a time when it's good to get input from the community about usage patterns, and IMO that's a valuable one to raise.

For instance, please don't require that components be script based, assuming that they're model components, and all rendering will be done in CFMs. I love the clean syntax of scripted components, and the similarity to other languages (except queries, kind of clunky). But in render-land, where you're outputting HTML interspersed with dynamic data, tag syntax is often more natural. In pure script, you have to build everything as strings and writeOutput() it, awkward, though you can of course do that when you think it's best. Allowing tag-based components gives you the flexibility to mix and match strategies as desired.

[Sean Corfield]

On Feb 12, 2015, at 4:40 AM, Dave Merrill <enig...@gmail.com> wrote:

For instance, please don't require that components be script based

I would be very strongly against allowing Lucee components to be written using tags. But of course you would be able to continue to write .cfc files using tags, if you like that approach.

[Kai Koenig]

For instance, please don't require that components be script based

I would be very strongly against allowing Lucee components to be written using tags. But of course you would be able to continue to write .cfc files using tags, if you like that approach.

+infinity — there’s no good reason why a Lucee component should be written in tags.

Cheers

Kai

[Dave Merrill]

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

[Kai Koenig]

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

To me, components hold control flow, model-type business logic, or view-helper code — if you want to take the component idea into the view layer.

Tags are really useful for augmenting html-based view templating, but there’s no need to do that in a component (As a side note: that’s also the reason why I think component-based custom tags as proposed by Micha don’t make any sense whatsoever).

Cheers
Kai

[Sean Corfield]

What Kai said. Plus: if you're going to go against the flow of common wisdom then being forced to use echo() and/or string concatenation in a script-based component is a good "penalty" to indicate that, yes, I'm really doing this unusual thing on purpose AND HERE'S WHY {insert explanatory documentation here}.

Like Kai, I'm also very skeptical of CFC-based custom tags. I think tag-based custom tags make far more sense, precisely for the reason that they're about HTML generation (for the most part).

One of the big problems that plagues CFML code is the mixing of logic and display code -- precisely because it's always been so easy to write logic in tags and therefore in amongst the HTML. Having the language really help you here by "strongly encouraging" a strict separation of logic from display code -- via script-for-logic and tags-for-display-code -- will produce better, more maintainable code, that is far more approachable to non-CFML developers.

Sean

[Andrew Penhorwood]

On Thursday, February 12, 2015 at 2:57:22 PM UTC-5, Sean Corfield wrote:
One of the big problems that plagues CFML code is the mixing of logic and display code -- precisely because it's always been so easy to write logic in tags and therefore in amongst the HTML. Having the language really help you here by "strongly encouraging" a strict separation of logic from display code -- via script-for-logic and tags-for-display-code -- will produce better, more maintainable code, that is far more approachable to non-CFML developers.

+1 on pointing the way on separation of logic and display code.  This is a major problem on most of the legacy applications I have worked on over the last 15 years.  I think Lucee should define this area better in the new .lucee flavor of things.

Andrew Penhorwood

[Sean Corfield]

On Feb 12, 2015, at 12:56 PM, Michael Offner <mic...@lucee.org> 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
> <loop times="5">
> #now()# <!--- no output necessary! --->
> <dump var=now()> <!--- attribute values with no " are handled as expression, not strings! --->
> <br><!--- ignored and outputed as it is --->
> </loop>
> 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.

[Michael Offner]

Tag based components

do you remember XHTML, the idea was to have a clean version of HTML, was it a success?

No!

from an architectural standpoint in totally agree, tag based components are ugly, no question about that.

BUT they can be convenient, if we get rid of tags in componens completely, people will start writing

echo('<p>#whatever#</p>');

for me there are 2 options:

1. still support tag based components

2. supporting tag islands in script

Example:

{{:<p>#whatever#</p> :}}

Tag prefix

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

<loop times="5"> 

   #now()# <!--- no output necessary! --->

   <dump var=now()> <!--- attribute values with no " are handled as expression, not strings! --->

   <br><!--- ignored and outputed as it is --->

</loop

the tags Lucee does not know are simply ignored then.

Micha

--

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/2019b5ab-9d80-4184-9890-f6e52e14fd02%40googlegroups.com.

[Adam Cameron]

Yup. I think burying markup in the middle of a function in a CFC is a bit grim, but if ppl want to do this: go for it. However if Lucee was to provide a new / different dialect in addition to CFM / CFC files (which is, remember, the plan here: tag-based CFCs are not going anywhere), I think it would be very poor decision to implement it as yet another tag-based language.

The merits of splitting the Lucee Association's development resource's focus to include a new dialect is already questionable (although one that sounds interesting). However if they then went ahead and just reimplemented something the same as CFML again, but different? A waste of everyone's time.

-- 

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/823A79B3-22BB-4FF3-B4EA-CBBC68C39DF5%40gmail.com.

[Sean Corfield]

On Feb 12, 2015, at 2:00 PM, Adam Cameron <dac...@gmail.com> wrote:

Yup. I think burying markup in the middle of a function in a CFC is a bit grim, but if ppl want to do this: go for it. However if Lucee was to provide a new / different dialect in addition to CFM / CFC files (which is, remember, the plan here: tag-based CFCs are not going anywhere), I think it would be very poor decision to implement it as yet another tag-based language.

I think the suggestion from Micha of "tag islands" was more to allow HTML as a first class data type with interpolations for content substitution, much like JSX for example.

And since the mood seems to be for a much more restricted tag language in .lucee view files, I would expect that same very restricted tag language to be the most that was available in "tag islands". Since the parser’s already there, it wouldn’t be a big deal for .lucee views and .lucee script "tag islands" to be exactly the same.

[Adam Cameron]

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

[Igal @ Lucee.org]

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

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

[Abram Adams]

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.

[Adam Cameron]

On Friday, 13 February 2015 11:31:04 UTC+13, 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.

Yup. "Separation of concerns" and all that sort of thing.

If one thinks one needs to start writing tags (where the intent of the tags would be specifically for preparing a string for output) in a component file, then one's gone off the tracks, I think.

If one has view-helper type things (which take a block of text and manipulate it for render), then I'd use a custom tag if anything.

-- 

Adam

[Igal @ Lucee.org]

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

[Igal @ Lucee.org]

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.

Igal Sapir
Lucee Core Developer
Lucee.org

--
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/0ec8da1f-c2d2-43e1-ac57-9aa2b98122a3%40googlegroups.com.

[Kai Koenig]

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

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

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.

Cheers
Kai

[Adam Cameron]

On 13 February 2015 at 00:32, Igal @ Lucee.org <ig...@lucee.org> 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.

 

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.

Well indeed. However you're eschewing all of those options, instead claiming that one might as well mix the tags and code into the same piece of code. Abram's merely suggesting the minimum level of abstraction.

-- 

Adam

 

[Kai Koenig]

On 13 February 2015 at 00:32, Igal @ Lucee.org <ig...@lucee.org> 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) :)

[Adam Cameron]

On 13 February 2015 at 00:37, Kai Koenig <grmb...@gmail.com> wrote:

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

I like the CFC-based custom tags because they better compartmentalise the before / after logic and the tag inheritance. I take a look at Railo's ones here: http://blog.adamcameron.me/2014/08/railo-cfc-based-custom-tags.html

However I still don't feel right putting any blocks of mark-up in them. If I needed an actual view or even a viewlet, I'd probably still factor that out into a separate file, and just include it when necessary.

-- 

Adam

[Igal @ Lucee.org]

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:

<cfcomponent name="UIRenderer">
   
    <cffunction name="renderSmallWidgetThumbnail">
        <cfargument name="widgetId">

        <!--- code goes here to render html with thumbnail, name, price, etc !--->
    </cffunction>

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

        <!--- code goes here to render html with thumbnail, name, price, etc !--->
    </cffunction>

    <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>
</cfcomponent>

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

--
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/F9D3D894-A4FC-48B8-B5EA-8C63C597426B%40gmail.com.

[Adam Cameron]

On 12 February 2015 at 21:06, Sean Corfield <se...@corfield.org> wrote:

 

> In my opinion we need no prefix for tags, so simply
> <loop times="5">
>    #now()# <!--- no output necessary! --->
>    <dump var=now()> <!--- attribute values with no " are handled as expression, not strings! --->
>    <br><!--- ignored and outputed as it is --->
> </loop>
> 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.

TBH, I'm all for actually maintaining the namespacing. The Lucee stuff is code and the mark-up is... well... markup. It doesn't seem right to actively remove that abstraction.

Then again I'm always the first to complain about "<cf" being everywhere in CFML code unnecessarily, so that's quite a paradox I have there. Hmmm.

-- 

Adam 

[Adam Cameron]

On 13 February 2015 at 01:01, Igal @ Lucee.org <ig...@lucee.org> 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.

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:

<cfcomponent name="UIRenderer">
   
    <cffunction name="renderSmallWidgetThumbnail">
        <cfargument name="widgetId">

        <!--- code goes here to render html with thumbnail, name, price, etc !--->
    </cffunction>

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

        <!--- code goes here to render html with thumbnail, name, price, etc !--->
    </cffunction>

    <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>
</cfcomponent>

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

-- 

Adam

[Igal @ Lucee.org]

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!

--
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%2BKcgcsghL-TZzz3zK_F0msqwCdbgHRXJs6PYyUVCs-620g%40mail.gmail.com.

[Kai Koenig]

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!

Jeez, could the two of you stop insulting each other, please? 

I will respond on topic in a minute.

*Sigh*

Kai

[Adam Cameron]

On Friday, 13 February 2015 14:17:21 UTC+13, Igal wrote:

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.

-- 

Adam

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

[Igal @ Lucee.org]

I merely agreed with Adam that there was a bigger difference between him and I.

I am always respectful in my replies, but some people here think that I owe them something, or whatever.  I don't. 

and Adam should not talk to me like that, nor to anyone else in this forum.

--
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/346FC818-E214-4A33-A908-9E3E8390D7C2%40gmail.com.

[Kai Koenig]

> 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

[Igal @ Lucee.org]

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

[Igal @ Lucee.org]

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.

[Kai Koenig]

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

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.

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

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

[Adam Cameron]

On 13 February 2015 at 18:04, Kai Koenig <grmb...@gmail.com> wrote:

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

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.

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

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.

-- 

Adam 

[Igal @ Lucee.org]

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

[michae...@arcor.de]

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

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 <cfsavecontent> with tags inside instead having to use manual string concatenation or a string builder..

[Abram Adams]

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:

<html>
<head><title>...</title></head>
<body>
<cfscript>

    oUIR = new UIRenderer();

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

</cfscript>
<div>other content...</div>
<footer>
   <cfoutput>#oUIR.renderPagination(...)#</cfoutput>
</footer>
</html>

Or do you think this would be clearer:

<cfimport taglib="/tags/widgets" prefix="widgets"/>
<html>
<head><title>...</title></head>
<body>
 <cfloop query="#searchResults#"> 
   <widget:thumbnail size="small" id="#widgetId#"/>
 </cfloop>
<div>other content...</div>
<footer>
   <widget:pagination pagesize="20" pagenumber="1" baseurl=".."/>
</footer>
</html>

Let's not let the 1% use case dictate the direction the language goes.  Please.

[Igal @ Lucee.org]

comments in text:

On 2/12/2015 10:23 PM, Abram Adams wrote:

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:thumbnail size="small" id="#widgetId#"/>
<widget:thumbnail size="large" id="#widgetId#"/>

<widget:pagination pagesize="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.

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.

--
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/47d84ac6-4b54-4a9d-be55-79fde7a61689%40googlegroups.com.

[Adam Cameron]

On Friday, 13 February 2015 19:39:45 UTC+13, Igal wrote:

I don't understand why the insistence to remove features that you guys don't like. 

No-one's suggesting removing anything from anywhere. 

We're suggesting they shouldn't go in in the first place. We're talking about .lucee, not .cfm/.cfc. You can do whatever you like with your CFML files. We just don't think it's a great approach and oughtn't be encouraged, therefore - if left up to us - isn't something that should be put into .lucee. It's work to implement it for .lucee, and not work that really would have much merit compared to applying the resources elsewhere.

-- 

Adam

[Abram Adams]

Igal, thanks for the kind words about trycf.  

I probably didn't make it clear in my post, but I'm not suggesting removing features.  I'm suggesting not to carry over things to .lucee just because.  Of course the way you code now would still work in cfcs.

I know folks can get a bit heated about this sort of stuff, and I'm not trying to add fuel to the fire, just trying to present a valid case for why I think tags in .lucee is a poor idea and solicit valid cases from those who think otherwise.  So far I honestly haven't seen any valid reason to add tags in .lucee.  Convenience of having all your rendering stuff in one file doesn't really sell the idea.  I've seen plenty enough of code written with that mindset.

[Michael Offner]

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"}];

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

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.

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.

[Michael Offner]

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

Micha

--
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/BEF9AFA4-67FD-4EE5-86B3-2098B935076B%40gmail.com.

[Michael Offner]

that brings it to the point!

Sometimes "separation" do unnecessary complicate things, you assume that this separation is always the better choise, but maybe it is sometimes not in the interest of the greater good (see my testbox example above).

Micha

--

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%2BKfTuQXEpB5HOYCPW4GO6AP8HPr6UrJia3LLXBNndfNA%2BQ%40mail.gmail.com.

[Michael Offner]

what makes again a simple custom tag mapping impossible...

again sometimes separation complicates things ;-)

Micha

--

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%2BKfnrRrnSfH2Lm7M3z9mv-ApvC-5nquq0%2BwvF57WEfDyFg%40mail.gmail.com.

[Michael Offner]

i like the idea that all tags are part of the language and you simply can chose to manipulate them or not.

Micha

--

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%2BKdjjFUVBGX%3DEPBkuW%3DbOnL-0s9xPb1E36LM1vdLAgiHfw%40mail.gmail.com.

[Michael Offner]

see my comments between the lines

Micha

On Fri, Feb 13, 2015 at 2:39 AM, Kai Koenig <grmb...@gmail.com> 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.

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("<br>");

 

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+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/BC3F190A-2FCF-4F47-A179-C148A86BE835%40gmail.com.

[Michael Offner]

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

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+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/A08CB133-72E9-4B3C-8F9B-4CE4633EEC8F%40gmail.com.

[Dominic Watson]

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 <cfparam> in the view to DECLARE what arguments it expects, is a really clean way to have self contained declarative views.

>    <cfparam name="args.expectedPararm" type="string" /> <!--- <<< 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 <cfinclude> 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.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBwDBgDBPRcSMCvcqKyy1Xqw4vyDutO112qPo-p1N%2BgaNw%40mail.gmail.com.

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: in...@pixl8.co.uk

Follow us on: Facebook Twitter LinkedIn

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

[Jean Moniatte]

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

je...@ugal.com

http://www.ugal.com

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBzVDffcoPPv8cvvtQRMHRSPOfVcNXhXT%2BzZDDzRC3eQfQ%40mail.gmail.com.

[Dominic Watson]

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...' )#

[Michael Offner]

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

--

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/CAEYvUx%3Ddj3g1txWR0AA-YT68ms%3D6xA9XpUXT%2BD%3DDmknXfyqqKQ%40mail.gmail.com.