Lucee Lang Namespace, why and if so what?

Now that you mentioned the closing slash, what a mess it is. It should either be required, or not and throw an error when typed. Having it work both ways is confusing. Not to mention how much it confuses the editors. But that’s another topic I think.

1 Like

I think the fact that few, if any, of us immediately knew the answer to the XML namespace legality question might indicate that most newbies might not care - only user testing of people learning the language may truly reveal the answer though.

I’m not averse to <:output> - I certainly like that there is less to type and the distinction between custom imported tag namespaces is refreshing too (as in Geoff’s example).

I like the <:sometag> namespace. I can live with whatever the group decides. I don’t like the version, to confusing on where that code is going to run. I am sure would be hard to parse too.

I kinda dig the no namespace <:tags>. It is a point of difference for the lucee language, and with its brevity, is a great match for my inherent laziness.

2 Likes

could you go with an empty namespace and have a setting somewhere (presume would need to be in a config file hidden somewhere) that allowed people to change it if they really had an issue with it OR if somehow it did turn out to conflict big time with something else then it could be changed quite easily - a little bit like jquery’s noconflict.

I don’t like the argument of less characters to type.
Code should be easily recognisable and understandable - commonly referred
to as readable.

​With a decent IDE I don’t have to go further than <cfo to get

I understand : to be using for imported namespace - in Geoff’s example​
(reverted to old school cfml)


<skin:breadcrumb separator=“/”
objectid=“#application.fapi.getNavID(“dmNews”)#” includeSelf=“true” />

​but if I am in a .lc (or .lucee) file
then the namespace of the dialect is implied, and therefore I would just use

and would expect my favorite IDE to help me out after I type <lco​

To be clear
I dont think lc:output is necessary

And to further labor the point, the general consensus seems to be only use
tags in views, where you are mixing with HTML tags.
You don’t have to ‘import’ lucee as a namespace, so why the need for ‘:’

Maybe if you had a .html and you imported lucee lc:outpout would make
sense
but is that even legit??
If Lucee pre-processed .html, I guess it might

So, in summary, I think the tag side of CFML works fine, no need to mess
with it.
Are you trying to be different just for the sake of it? Seems a little to
cute and try hard for me.

I do like the <:tag name /> style.

I like the idea that @micstriit showed on how a lib/framework could be used like <susi:whatever>

Though maybe it would be clearer for a dev that this is lucee tag. So something like this <:susi:whatever>

If we stop thinking about XML and their implementation of namespaces we could have a syntax like <:namespace:tagname> So the idea of having no namespace by default would be fine <:luceetag>

Yes, I actually would be.

That is actually a good idea. Either allow it or not allow it, but not the current mish-mash of whatever one feels like today.

Ok, so it seems there is consent on the fact that no one really cares about making this XML-compliant. That’s ok.

If I take this as a premise, then let’s maybe think a bit out of the box. Why does it have to be tags in the first place? Just because CFML or HTML use tags? Another thing to think about it readability of ones code.

I just typed a bunch of Lucee-code with the empty namespace syntax into my IDE and I think it looks messy and hard to read, you sink into a sea of tag brackets and colons. Not nice.

If we wanted to stick with tags AND wanted to use an “empty namespace”, can we potentially find a better character to use than the colon? Under the premise of this not being a real XML namespace, who cares, right?

So, let’s look at those:

  • <-output>
  • <;output>
  • <,output>
  • <@output>

The first to third having the advantage that the don’t need hold the shift key on an en_US keyboard. The third actually even better because it’s the same key as the <.

And just in case you think I’m joking, I’m not!

FWIW, my “Iris” vote was for <i:tag> or <ir:tag> and translated to Lucee that would be <l:tag> or <lc:tag>. However, @micstriit is correct that the majority vote was for “no prefix” and now I’ve seen it implemented, I rather like it. It clearly delineates HTML vs Lucee tags, it’s short, it’ll be easy for IDE/editor plugins to deal with (since <: and </: will be trigger strings).

1 Like

would having valid XML tags make it easier for IDEs to do their magic?

Even if it was possible, I don’t think it would be necessary :smile:

Yes, XML tags make life easier for IDEs etc but if / else etc becomes really horrible if you try to make it XML-compliant. Seriously, it’s just not somewhere you want to go :slight_smile:

We solved that, Lucee has a setting with tag libaries to ignore unknown tags or not. So let’s say the parser comes to the “img” tag, it checks if there is a tag available for this, if not is is simply ignore and outputted as it is.

Specially because you can also do:

<cfset age=whatever>
<cfset name='Susi'>

in clean xml my first example need to look like this

<cfset age="#whatever#"/>

but even worse, take that example

<cfif name == "Susi">Hi Susi<cfelse>Hi there!</cfif>

in clean xml this need to look like this.

<cf:condition>
 <cf:case cont="#name == "Susi"#">Hi Susi!</cf:case>
 <cf:else>Hi there!</cf:else>
<cf:condition>

Before i started Railo, i have written a JSP library that provided the “CFML enviroment” (some CFML tags), but that was horrible, lot to much overhead to code.

1 Like

for me this could also be an option:

<@set test=1>
<<set test=1> <!--- like this ---> vs. <!-- this --> or /** this */ vs. /* this */

but my favorite still is

<:set test=1>

what would interest me, if there would still a CFML tech comitee in place and Adobe and Lucee would ask if you would like if we add “:” to the tags to the tags (backward compatible of course), so that you could write

<cf:set test=1>

or

<cfset test=1>

would you like that and would you use that, so what you prefer!

I’m asking because nobody sugessted

<luset test=1>
<lcset test=1>

so a prefix with no delimiter.
btw we can also choose a different delimiter, so this could be an option as well

<lu-set test=1>
<lu.set test=1>

looks not that boring like

<lu:set test=1>

We agree that code should be readable, though in this scenario I don’t think a namespace contributes to its readability.

Edit: In summary, +1 for no namespace on <:tags>

1 Like

silently ignored code, while convenient for this purpose, seems like a bad idea to me. I’m having trouble coming up with an example that would be something commonly done in views that would be a problem, but it just rubs me the wrong way.

1 Like

I love the energy and love CFML is getting and how Lucee is spurring that.

For me, the best parts of Lucee is it is CFML. For the love of CFML is that its very much like HTML and I can pick up a book written nearly 10 years ago and it still remains just as relevant as it did back when it was written.

I know as programmers we are tinkers and We love to do things better. We evolve over time and my coding is always improving.

One thing I will say is, if you start changing
<cfset = “something”>

to
<:=“something”>

It gets lost.

Instead of changing widely accepted syntax I’d rather see more features. More expanded options in CFML itself.

It would be cool if CFML via Lucee could do the following things

Store query of queries to a memory variable inside a security container, so you could say pass the result of a query of a query to another application container or script, with a predefined or option security key or encryption in memory.

More ajax widgets. such as “CFCRUD” or “CFDBA” or “CFMENU” “CFNAVBAR” “CFFLOATNAV” “CFMODEL” “CFPOPUP” “CFPOPBEHIND” “CFCAPTCHA”

Better memory management for per instance hosting of Lucee. I know it can be tweaked per installer on the command line, but support for items would make it easier to get commercial items such as Cpanel to integrate it into their product.