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: GitHub - tc39/proposal-Array.prototype.includes: Spec, tests, reference implementation, and docs for ESnext-track 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.On Saturday, February 7, 2015 at 2:24:12 PM UTC-6, Adam Cameron wrote:
On Sat, Feb 7, 2015 at 8:53 PM, Sean Corfield <se...@corfield.org <javascript:>> 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:
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 <javascript:>> 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
