Tag and script in the same file (Lucee Language)

[agentK]

@kliakos

@21Solutions

I totally disagree.

that would slow down development, and slow down execution. I see only downside and no upside.

if you prefer to do it that way in your code – go for it – you can do it that way right now and no modification to the engine is required. but that doesn’t mean that everybody should be forced to do it that way.

+1. Definitely will slow down development. And CFML is all about easy and rapid development, not complicated stuff.

So, we go back to chucking everything into an abc.cfm file? The reality is that this “style” of “rapid” development is exactly where CFML has its bad rep from. Therefore Lucee should NOT allow people to build the same type of stupid “architectures”.

[kliakos]

Doesn’t java(jsp) and php do the same thing? It is very common I think.

[justincarter]

@agentK

So, we go back to chucking everything into an abc.cfm file?

If someone wants to write all their code in a single file because it’s the best way to solve a particular problem then they should be allowed to, but in this case it’s helpful to consider the use of tags in script based components as well

[modius]

@agentK

So, we go back to chucking everything into an abc.cfm file? The reality is that this “style” of “rapid” development is exactly where CFML has its bad rep from. Therefore Lucee should NOT allow people to build the same type of stupid “architectures”.

Are you advocating that the language should define much more strictly how to write the “right” code than other web oriented languages? Will this lack of choice be one of the features of the Lucee language?

I agree this is a very real problem in all coding communities – not just CFML. Maybe more so in CFML due to the lower barrier to being “productive”.

But… this sounds a lot like the XHTML battle. And we all know how that turned out.

There has been a lot of criticism over the years as to the lack of structure in Javascript – and we’ve certainly seen some interesting implementations evolve over the years in Javascript development that would not have been possible if the language was more prescriptive. It took leap-frogging frameworks like prototype, moo-tools, jquery, angular, etc to get to where JS development is today. Looking back at early Javascript code is very often more scary than looking back at old CFML code bases.

I think we should be very cautious about rushing down the road of implementing a language that is more and more Java-like than HTML-like. One of the enduring reasons CFML is popular is because it is approachable, and looks at first glance like a sort of HTML+.

Surely we should be striving to maintain that approachability, while improving the underlying language to allow frameworks that enforce stricter coding standards to flourish?

[seancorfield]

Common, perhaps. Good practice, no. Both Java and PHP provide better ways to organize your code that avoid putting logic in the views. Quite a few languages heavily restrict what logic can go in a view anyway, and some languages don’t allow it all, relying instead on “templating libraries”.

Restricting tags in a view to just basic conditionals and loops, possibly with the option of a script block if you really must have logic there, seems a reasonable approach to me.

After all, if you want to continue to mix logic in with your views, use a .cfm suffix on your view and continue to write CFML

[modius]

@seancorfield

Both Java and PHP provide better ways to organize your code that avoid putting logic in the views.

But don’t both allow you to put logic in your views if you choose to?

Why aren’t we talking about providing “better ways to organize your code that avoid putting logic in the views” for Lucee Language rather than restricting the ability to put logic in the view if you choose to?

[seancorfield]

@modius

But don’t both allow you to put logic in your views if you choose to?

Those languages do, other languages restrict or disallow. See the new thread on language philosophy.

[fingersdancing]

@seancorfield Reading between the lines it would seem you want the language philosophy to be completed before discussions like this start?

[agentK]

@modius

@agentK

So, we go back to chucking everything into an abc.cfm file? The reality is that this “style” of “rapid” development is exactly where CFML has its bad rep from. Therefore Lucee should NOT allow people to build the same type of stupid “architectures”.

Are you advocating that the language should define much more strictly how to write the “right” code than other web oriented languages? Will this lack of choice be one of the features of the Lucee language?

You’re framing it the wrong way I think, but essentially the answer is yes.

I wouldn’t see it as a lack of choice (obviously it is in the endgame), but a way to promote good architecture and separation of concerns.

@modius

But… this sounds a lot like the XHTML battle. And we all know how that turned out.

The XHTML battle is different because there were browser vendors and therefore a variety of constantly changing runtime environments involved.

@modius

I think we should be very cautious about rushing down the road of implementing a language that is more and more Java-like than HTML-like. One of the enduring reasons CFML is popular is because it is approachable, and looks at first glance like a sort of HTML+.

Surely we should be striving to maintain that approachability, while improving the underlying language to allow frameworks that enforce stricter coding standards to flourish?

Your take on it is fair enough, I choose to disagree → making it more HTML+ like will lead to the same issues in perception that ColdFusion and CFML in general has. I’m not saying a language shouldn’t be easily approachable. However that doesn’t mean that you need to allow people to and directly or indirectly promote writing bad code.

[agentK]

@fingersdancing

@seancorfield Reading between the lines it would seem you want the language philosophy to be completed before discussions like this start?

That’d be very advisable, wouldn’t it?

[seancorfield]

@fingersdancing

it would seem you want the language philosophy to be completed before discussions like this start?

I think having a clear statement of the vision for the Lucee language would help head off a lot of the sorts of unproductive discussions that quickly go off into the weeds, yes. It doesn’t have to be a thesis, just some guiding principles that give a sense of what is “possible” (within the context of cleaning up CFML to create Lucee) and what should be considered “off the table”.

That way, even if folks don’t agree with that published philosophy, discussions could at least be conducted within those boundaries – which should help keep things more on-topic.

[fingersdancing]

+1 @seancorfield

[micstriit]

@modius

I fully disagree. And I’m sure I’m not the only one.

me to +1

This is a conceptual decision made by the developer(s), it is not up to the language to define a limitation like this.