Script or lucee tag?

Firstly this is ultra trivial, so feel free to ignore.

In the Namespace discussion @21Solutions said:

Which got me thinking, should it be “script” in the Lucee dialect or should it be “lucee” instead. For example in php you have:

    a = b;

So why not in Lucee have:

    a = b;

I’m not suggesting this to solve the namespace issue that Igal was suggesting would exist, I’m suggesting it as I think it is nicer than having the word “script”, more clarity as to what it actually is, it is not just “script” it is “lucee”…


it was just an example to show the ambiguity. it was the first tag that came to mind that is used both on the server and client, but IIRC there was at least one more like that.

<cfcol>, <cfapplet>, <cftable>, <cfform>, <cfinput> [then I stopped looking.

(Dunno if Lucee has all these ones: I was looking @ Adobe’s docs)


Did neither of you read the last paragraph on my post?

Yup. I was replying to Igal, not you. That’s not made terribly (or “at all”, as far as I can tell) clear by the Discourse UI, sorry. I should have included some context. Although I thought it was pretty clear by what I said?

And Igal was probably harking back to the earlier conversation (still: around whether to have a prefix, a namespace, no namespace, etc.

But anyway, to answer your question… <cfscript> (and accordingly <:script>) is not distinguishing between HTML or PHP or some other language, it’s distinguishing between tags and… erm… script syntax within the same language.

So calling it “<:lucee>” doesn’t make any sense, as <:loop> is just as much part of .lucee as any given script construct (there’s a case in point: I needed to say “script construct” not “lucee construct” to disambiguate the two).

A better question should be whether script and tags should be allowed to cohabitate in the same file anyhow. However that’s an arg^h^h^hdiscussion for another day.


I kind of like it, but for the point that Adam raises, you’re already coding Lucee - the tag itself is Lucee! Logically, I think it would be most clear as <:luceescript>, but then, that’s a little verbose. Given that the : is indicating “this is lucee”, <:script> is sufficient I think.

Just a slight point here, and this point is getting very theoretical, but think this is the level the thinking should be at when designing a language. And I like to think about stuff.

Also I’ll put it up front that whilst I think the empty namespace is a poor idea, I’m not really that fussed. But now is the time we should be thinking about this.

The absence of a namespace doesn’t mean “this is Lucee”, it means “I make no claims as to what this is”. You infer it means Lucee because of the context of it being in a .lucee file, and you are arriving at that file already knowing this. Obviously one can easily do that. But should one do that? IE: should that be how this is resovled?

The thing with populated namespaces is that the prefix does indicate “this is [whatever]”, as it correlates back to the namespace declaration earlier in the doc). This namespace decl. could be in a tag or could be in a taglib import statement or implied or whatever.

In the context of a file full of HTML which is ultimately going to be streamed back for the intent to be used as HTML in a bigger repsonse, then the raw HTML “namespace” needs to win out for the sake of expediency (imagine needing to type out “<html:br>”!), so it’s just presented as HTML. From there, any non HTML should be (well: “could be”, but we’ve erred towards “it will”) presented with a namespace to identify it.

We should bear in mind that .lucee code will not exist in a vacuum. It might be being used where other taglibs are being used, and the idea being namespaces is to disambiguate between the libs. For example in our views we’d be using our own custom tag libraries, and/or someone else’s custom tag libraries, or just have multiple custom taglibs of our own, etc. Or I guess even in other mark-up which already uses namespaces: generating XML or [some future thing which becomes all the rage]. The point being, namespaces work the way they do for a reason: a bigger picture.

We also need to think that .lucee doesn’t exist in a vacuum in the context of how namespaces in tag-like text works. But rather from the perspective of the rest of the industry. It’s true that a .lucee file isn’t XML and makes no claim to be. However we are borrowing syntax from XML… I mean we have chosen to use “<[blank]:tagname” as our syntax, and do indeed claim the colon is the namespace separator. So we’re borrowing from XML. But in the next breath some of us are going “no we’re not using XML” when countering the suggestions that XML namespaces usually aren’t empty. If we didn’t want to run with the way XML does its namespacing… we could have used a prefix instead (ie: "<[prefix][tagname]", “<cfclient”).

I think we’re using broader industry conceits, but then only thinking very locally in its implementation, ignoring the way the broader industry does things. I think this is not the way other languages’ design decisions are generally made. We still seem to be slightly stuck in the “everything is our own little world” that CFMLers tend to reside in.

On the other hand, so far the only legit (-ish) rationale for not using an actual namespace is “it saves typing”, which I think only stands up if one is in a typing race. That said, some have indicated they think that they are, so I can see where that comes from.

@alexskinner made a valid point earlier than “<l:” and “<lc:” is unclear as to whether it’s a “1” or an “l” or an “I”. This is true when taken out of any context. However it only becomes relevant in a context where there a mix of two or more of those possibilities. In a source code file you’re looking at: “<lc:” means “Lucee”. It’s an L. If you then import another taglib and choose to use one-cee or eye-cee as its prefix: more fool you.

So I think the lack of namespace prefix has been justified via excuse, rather than via rationale.

Still, like I said… I don’t care so much I suppose. I’m more like juror 12 in 12 Angry Men who just wants to hold up the decision for a bit whilst we think about it some more.

And whichever approach is ultimately taken: I don’t think it’ll be the end of the world one bit… the code will still work [grin].

Cheers for wading through all that!


If you approached it from the point of view that that all files could be treated as script, then you might be able to say that <:script> is redundant.

However, this would rely on having a way to use tags where they are needed :slight_smile:

in the beginning the Lucee dialect had no prefix at all, so script was first named “scriptX” then later “lucee”… :wink: