Tag and script in the same file (Lucee Language)

Regardless of the merit of such a statement, we should not be limiting people’s options without there being a good reason; for example, performance.

If I found myself writing a view where i had little choice but to put in a bunch of variable assignments and/or conditional logic it would be very frustrating to be prohibited from using a script block because somebody “knew better”.

And <:include> is rarely where I would want anything to belong :wink:

There are plenty of legitimate reasons for wanting to simplify things in <:script> in the midst of a template full of tags. If you don’t want to mix <:script> with tags then don’t.

@fingersdancing - the parser needs to know whether it’s trying to parse tags or script. there should be a clear separation.

keep in mind that a tag is not necessarily a tag. it can be literal text as well. e.g.

for (i=1; i<=10; i++) {

   Hello <em>there<em>!  // Hello is literal string that should throw an error
}

as opposed to:

for (i=1; i<=10; i++) {

   {{
   Hello <em>there<em>!  <!--- parser knows this is literal string !--->
   }}
}

Totally agree also. Maybe it is bad as an idea to mix views and data retrieval, but it sometimes is the fastest way to do things, without actually writing ugly code.

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

@21Solutions why does there need to be a clear separation of tags and script? All tags start with “<:” and I don’t know of an operator or expression in script which is that. So is that is not a clear identifier of a tag expression starting/ending?

We need to consider other tags not just cfoutput or cfsavescript. Just thinking about those two is a narrow view of the discussion around having tags in script. Mail is one example of another tag but there other tags which don’t exist yet and we need to consider them in this discussion.

for (i=1; i<=10; i++) {
  <:mail to=person[i]>
    <:text>
      hey #person[i].name#
    <:/text>
    <:html>
       <h1>hey #person[i].name#</h1>
    <:/html>
  </:mail>
}

To me this is a core switch of the defacto arrangement that everything is tags or whitespace and then you explicitly state script in blocks of script tags. So if everything is script by default then you need to explicitly state tags and once inside a tag you must maintain tags.

So to output i + the tick count (assume it is 10) would do something like this

i = 10;
<:output><:set i += getTickCount()/>#i#<:/output>

std output>20

compare to here where the “script” would be treated as a string.

i = 10;
<:output>i += getTickCount()#i#<:/output>

std output>i += getTickCount()10

If we need to add the tag islands it should be because it supports developers is some manner. Having to write a tag island each time I need to do a tag in script seems like an inconvenience to me. I can’t how it is making development better so given the choice I would not have tag islands.

That’s right, there could be a lot of scope to add a new dimension to the language. If you take the position that all files should be treated as script but you allow other tags to be usable in some way when needed or desired, then there is possibly no need to use the <:script> tag :slight_smile:

You could simply output something:

person = new Person({id: 1234})

<:output>
Hi #person.name()#!
</:output>

You could capture output to do something with it later:

person = new Person({id: 1234})

out = <:output>
  Hi #person.name()#!
</:output>

Or you could run a query:

function findPerson() {
  var qPerson = <:query>
    SELECT * from person
    WHERE id = 1234
  </:query>
  return qPerson
}

Or you could work with custom tags that output something (and/or capture it as in this example):

import taglib="/farcry/core/tags/webskin" prefix="skin";

function getView(objectid, webskin) {
  var out = <skin:view objectid="#objectid#" webskin="#webskin#">
  return out
}

Or custom tags that return data (rather than passing in a string attribute for the variable name to set in the caller scope or some other global scope, i.e. r_chart="stData").

import taglib="/orgchart" prefix="org";

qPeople = getPeopleByOrganisationID(10)

stData = <org:chart data=qPeople>
  <org:department id="5">
    <org:title>IT</org:title>
  </org:department>
</my:orchart>

Or work with XML:

xml = <:xml>
  <people>
    <person>Bob</person>
    <person>Susi</person>
  </people>
</:xml>

So it might be possible to allow the use of tags wherever they are needed or desired without the need for a special “tag island” block. The tags themselves could probably serve that purpose? And of course, it’s just an option for those who need it :slight_smile:

1 Like

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

1 Like

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

I moved 4 posts to a new topic: Off topic waste paper bin

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

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?

1 Like

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

1 Like

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?

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

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

1 Like

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.

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

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.

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

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.

1 Like

+1 @seancorfield

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.

2 Likes