Alternative templating schemes

My 2 cents
Stop diluting the merits of your contribution. Even if I don’t agree
with it :wink:

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.On 8 February 2015 at 16:23, Ryan Guill <@Ryan_Guill> wrote:


Adam

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

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

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.On Sunday, February 8, 2015 at 10:37:13 AM UTC-6, Adam Cameron wrote:

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

My 2 cents
Stop diluting the merits of your contribution. Even if I don’t agree
with it :wink:

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.

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> On 8 Feb 2015, at 16:25, Ryan Guill <@Ryan_Guill> 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 PenhorwoodOn Saturday, February 7, 2015 at 3:38:42 PM UTC-5, Micha wrote:

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?

DaveOn Saturday, February 7, 2015 at 3:56:05 PM UTC-5, 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. 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 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 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

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

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

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

On Sunday, February 8, 2015 at 8:55:39 AM UTC-6, Adam Cameron wrote:

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

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


Adam

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

I think the tag for views is fine.
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
@Gavin_Pickin
http://www.gpickin.comOn Feb 7, 2015, at 4:39 PM, Andrew Penhorwood <@Andrew_Penhorwood> wrote:

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


You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/f5d7b045-fa86-41d3-8ba8-bd791189f409%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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> On 9 February 2015 at 01:20, Adam Cameron <@Adam_Cameron1> 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:
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.

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 ;-)On Saturday, 7 February 2015 20:56:05 UTC, Ryan Guill wrote:


Adam

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’

ASent from my phone
On 8 Feb 2015 16:37, “Adam Cameron” <@Adam_Cameron1> wrote:

On 8 February 2015 at 16:23, Ryan Guill <@Ryan_Guill> wrote:

My 2 cents
Stop diluting the merits of your contribution. Even if I don’t agree
with it :wink:

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.


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

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?"On 9 February 2015 at 01:20, Adam Cameron <@Adam_Cameron1> wrote:

I think this is a good point Abram. This is why 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.On Saturday, February 7, 2015 at 1:52:53 PM UTC-6, Abram Adams wrote:

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

someVar = "def";
{{someVar}} {{someVar}}

What would the the output be?

On Saturday, February 7, 2015 at 10:58:36 AM UTC-8, Adam Cameron wrote:

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

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!On 8 February 2015 at 16:39, Alex Skinner <@Alex_Skinner> wrote:


Adam

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


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

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> 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 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 ( :wink: ) is raising some security
questions for me. Technically it is no problem with lucee 5.

MichaOn Sunday, February 8, 2015, Mark Drew <@Mark_Drew> wrote:

On 8 Feb 2015, at 16:25, Ryan Guill <@Ryan_Guill <javascript:_e(%7B%7D,‘cvml’,‘@Ryan_Guill’);>> 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


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

@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.On Sunday, February 8, 2015 at 9:20:24 AM UTC-5, Adam Cameron wrote:

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

Plus a bunch for this Ryan.

I’ll get back to Ryan separately. :expressionless:

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

Personally, I would prefer a short tag syntax for output and getting rid of completely. I find escaping #’s is a hassle and eliminating without a short tag option would require it in all templates (or you would have to go back and add ’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

#myVar#

or

writeOutput(myVar);

-JonOn February 10, 2015 at 2:44:43 AM, Michael Offner (@Michael_Offner) wrote:

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

Micha

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


You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFwR%2BKdtP7zoKP1YCs3ik1iioGLoB0RZzd%3D2Eso_FC50ba5nNQ%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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/2A49BB73-4921-431A-9A83-74D630F08DED%40web-meister.com.
For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEByT8tuA%3D%2BszzffHn_vv7vhiA7Gu3zEa4hRV%2Bpap8G1DjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

There you go, an approach that doesn’t break existing apps, I like it
().On Tuesday, February 10, 2015 at 2:44:41 AM UTC-5, Micha wrote:

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

Micha