Lucee Lang Namespace, why and if so what?

[alexskinner]

And when there is no namespace how do you mark you views to tell lucee that it’s an html tag and not to process it. You actually do what to output an img tag. Any store of tags needs to be adjustable and it feels wrong for lucee to need to have any understanding of the markup its generating.

Personally I would be very comfortable with l: but is that a 1 or an I or l. Plus when you write out html markup with imported custom tag line u get a visual segmentation between http markup, imported tag namespace and core tags more so than you do otherwise

I’m very against no namespace

[isapir]

@alexskinner

I’m very against no namespace

+1

where does <script> get processed? on the server side or the client side?

[agentK]

@alexskinner

And when there is no namespace how do you mark you views to tell lucee that it’s an html tag and not to process it. You actually do what to output an img tag. Any store of tags needs to be adjustable and it feels wrong for lucee to need to have any understanding of the markup its generating.

Personally I would be very comfortable with l: but is that a 1 or an I or l. Plus when you write out html markup with imported custom tag line u get a visual segmentation between http markup, imported tag namespace and core tags more so than you do otherwise

I’m very against no namespace

It seems the majority of people think we need something on the namespace-end — and I tend to agree, no namespace is an issue and will lead to confusion and mixup re tag names etc.

I’m more and more leaning towards not liking the “empty”/: namespace approach as

• It looks weird (and that’s a purely personal preference, @micstriit sees it as fresh and that’s ok to)
• I wonder if it is actually even a “legal” namespace in XML — and yes, LuceeLang might not HAVE to be XML compliant, but don’t fool yourselves — people looking at it or approaching it from a newbies point of view will feel more familiar with it if it looks like properly namespaced XML)

From that point of view something like lc:dosomething is an approach I’d probably prefer over the empty namespace.

[modius]

I was solidly in the <lc:tagname> camp but the “empty” namespace syntax (<:tagname>) grows on you over time.

I think @micstriit has a point; the <:tagname> syntax does look different yet familiar. Fresh? Yeah, maybe. <lc:tagname> makes me think i’m working with a simple JSP tag library, when Lucee is so much more than that.

Applying it to actual tag based views doesn’t look at all out of place to me:

<:setting enableoutputonly="true"> 
<!--- @@displayname: News body --->
<!--- @@postprocess: youtube(width=720,height=405);vimeo(width=720,height=405);twitter --->

<:import taglib="/farcry/core/tags/webskin" prefix="skin" />

<:output>
	<div class="page-header">
		<skin:breadcrumb separator="/" objectid="#application.fapi.getNavID("dmNews")#" includeSelf="true" />
		<h2>#stObj.title#</h2>
		<p><span class="date">#application.fapi.prettyDate(stObj.publishDate)#</span></p>
	</div><!-- /page-header -->
	#stObj.body#
</:output>

<:setting enableoutputonly="false">

I don’t mind it at all.

@agentK

I wonder if it is actually even a “legal” namespace in XML

If the empty namespace were a legal namespace, would you be happy with that approach?

[justincarter]

The empty namespace does look strange at first, and is even harder to type; I still haven’t decided if I like it but I’m not entirely against it I may be starting to prefer it over l: or lc:…

As far as XML is concerned an empty string for a namespace is not legal, but I don’t think that should influence any decision, because this is obviously not XML and shouldn’t be treated as such.

http://www.w3.org/TR/REC-xml-names/

2.2 Use of URIs as Namespace Names
The empty string, though it is a legal URI reference, cannot be used as a namespace name.

(Unless namespace name here is not refering to the prefix, it goes on to say: “The Prefix provides the namespace prefix part of the qualified name, and MUST be associated with a namespace URI reference in a namespace declaration.” I can’t quite tell…)

The “no namespace” probably isn’t an option due to clashes, unless <script> was redundant. Even then it would most likely be confusing to work with, readability wise.

[isapir]

@justincarter

As far as XML is concerned an empty string for a namespace is not legal, but I don’t think that should influence any decision, because this is obviously not XML and shouldn’t be treated as such.

+1

I don’t see what xml compliance have to do with anything. as soon as you write:

<cfset name = "Lucee">

instead of

<cfset name = "Lucee"/>

your markup is not xml compliant.

[kliakos]

@21Solutions

I don’t see what xml compliance have to do with anything. as soon as you write:

<cfset name = “Lucee”>

instead of

<cfset name = “Lucee”/>

your markup is not xml compliant.

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.

[dom_watson]

@agentK

people looking at it or approaching it from a newbies point of view will feel more familiar with it if it looks like properly namespaced XML

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

[apenhorwood]

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.

[chapmandu]

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.

[Chopki]

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.

[webonix]

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.

[fingersdancing]

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>

[agentK]

@modius

If the empty namespace were a legal namespace, would you be happy with that approach?

Yes, I actually would be.

[agentK]

@kliakos

@21Solutions

I don’t see what xml compliance have to do with anything. as soon as you write:

<cfset name = “Lucee”>

instead of

<cfset name = “Lucee”/>

your markup is not xml compliant.

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.

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.

[agentK]

@fingersdancing

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>

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!

[seancorfield]

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

[webonix]

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

[justincarter]

@webonix

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

[seancorfield]

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