People still will migrate existing apps, so compatibility is relevant to a
certain point.
MichaAm Montag, 9. Februar 2015 schrieb 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.
On 9 February 2015 at 12:24, Dave Merrill <@Dave_Merrill <javascript:_e(%7B%7D,‘cvml’,‘@Dave_Merrill’);>> wrote:
@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.
I like the current scheme a lot, I only ask myself if we should get rid of
completely .
Maybe adding a instead that ignore all #.
MichaAm Montag, 9. Februar 2015 schrieb 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 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”.
On Feb 9, 2015, at 7:31 AM, Adam Cameron <@Adam_Cameron1 <javascript:_e(%7B%7D,‘cvml’,‘@Adam_Cameron1’);>> wrote:
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.
On 9 February 2015 at 12:24, Dave Merrill <@Dave_Merrill <javascript:_e(%7B%7D,‘cvml’,‘@Dave_Merrill’);>> wrote:
@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.
Man I hate that embedded tag stuff. It always wants to wreck my editor
color coding. I prefer:
SomethingOn Saturday, 7 February 2015 16:09:48 UTC-5, Raymond Camden wrote:
>
> I like this list as well, with 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" "something">selected>Something
>
>
> 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 wrote:
>>
>> On Sat, Feb 7, 2015 at 7:47 PM, Abram Adams 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 … syntax but with
>> only a small subset of tags actually available? Maybe just:
>>
>> *
>> *
>> *
>> * - if you really must embed logic, at least make it script!
>>
>>
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
On 12 February 2015 at 18:33, Kai Koenig <@Kai_Koenig> 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.
+infinity — there’s no good reason why a Lucee component should be written
in tags.
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.On Friday, 13 February 2015 11:31:04 UTC+13, Abram Adams 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:
“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.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 <javascript:>> wrote:
On Sat, Feb 7, 2015 at 7:47 PM, Abram Adams <cfxc...@gmail.com <javascript:>> 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.
+infinity — there’s no good reason why a Lucee component should be written in tags.
This was something I pushed for on the CFML Advisory Committee and I still think is a good idea, if we can agree on a nice syntax for it. I’d be OK with {{: … :}} but I’d like to see some other suggestions.
In my opinion we need no prefix for tags, so simply
#now()# <!— no output necessary! —>
<!— attribute values with no " are handled as expression, not strings! —>
<!— ignored and outputed as it is —>
the tags Lucee does not know are simply ignored then.
Fair enough. I like some prefix just because it makes it easier to find “code” in amongst the markup.
“Perfection is the enemy of the good.”
– Gustave Flaubert, French realist novelist (1821-1880)On Feb 12, 2015, at 12:56 PM, Michael Offner <@Michael_Offner> wrote:
Sean and Kai, can you explain why component-based views seem like such a
bad idea to you?On Thursday, February 12, 2015 at 1:33:53 PM UTC-5, Kai Koenig 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.
+infinity — there’s no good reason why a Lucee component should be written
in tags.
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.
SeanOn Feb 12, 2015, at 11:42 AM, Kai Koenig <@Kai_Koenig> wrote:
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).
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.
On 12 February 2015 at 19:38, Dave Merrill <enig...@gmail.com <javascript:>> 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”.
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).
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(‘
#whatever#
’);
for me there are 2 options:
still support tag based components
supporting tag islands in script
Example:
{{:
#whatever#
:}}
Tag prefix
In my opinion we need no prefix for tags, so simply
#now()# <!— no output necessary! —>
<!— attribute values with no " are handled as
expression, not strings! —>
<!— ignored and outputed as it is —>
</loop
the tags Lucee does not know are simply ignored then.
MichaOn Thu, Feb 12, 2015 at 9:24 PM, Andrew Penhorwood <@Andrew_Penhorwood> wrote:
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.
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> On Thursday, February 12, 2015 at 2:57:22 PM UTC-5, Sean Corfield 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”.On 12 February 2015 at 19:38, Dave Merrill <@Dave_Merrill> wrote:
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.
“Perfection is the enemy of the good.”
– Gustave Flaubert, French realist novelist (1821-1880)On Feb 12, 2015, at 4:40 AM, Dave Merrill <@Dave_Merrill> wrote:
For instance, please don’t require that components be script based
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.On Tuesday, February 10, 2015 at 8:41:48 AM UTC+1, Micha wrote:
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.
“Perfection is the enemy of the good.”
– Gustave Flaubert, French realist novelist (1821-1880)On Feb 12, 2015, at 2:00 PM, Adam Cameron <@Adam_Cameron1> 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.
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.
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.
On 12 February 2015 at 19:38, Dave Merrill <@Dave_Merrill mailto:Dave_Merrill> 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”.