Lucee Lang Namespace, why and if so what?

language
1

So that is the question to explore in this topic… what does everyone think?

The general argument for a namespace is that we would need a namespace in the tag syntax to differentiate the “Lucee” code from the HTML that will surround it, because of course you will only use tags in views, otherwise in the future the HTML specification might add a new tag that conflicts with one of the Lucee tags and the namespace protects from this. However personally I don’t like the colon, to me it just looks and feels awkward. Take for example:

<cfif a EQ b>
    <cfset c = d>
</cfif>

compared to:

<:if a EQ b>
    <:set c = d>
</:if>

I’m not sure if it is just I find the first familiar and the second not but the colon is just not feeling right to me. Particularly on the closing tag for some reason where you have both the slash “/” and the colon “:”. Now removing the namespace all together, e.g.

<if a EQ b>
    <set c = d>
</if>

Looks and feels very nice and I think that without the namespace you could do some clever stuff, e.g. you could define an override for an HTML tag, e.g. the img tag:

<img src="/images/myimage.jpg" width="50" height="50" crop="center center" resize="true" maintainaspect="true'>

And if myimage.jpg was say 500x250 it would resize the image to 100x50 (maintain aspect) and then crop it around the center and return a 50x50 image in an html tag:

<img src="/whatever-temporary-source-file-is.jpg" width="50" height="50">

However if you had just:

<img src="/images/myimage.jpg">

Then Lucee would just ignore this as it is clearly just HTML with no additional arguments for Lucee to interact with.

You could do all sorts of dynamic HTML view layer things like this then. This to me would be a good argument for not having a namespace in the Lucee dialect.

2

I echoed this sentiment last time this conversation came up, so I’ll simply reiterate it for the purposes of this thread and then leave it at that.

I’m kind of with Andrew in that the null-namespace looks odd. And my position is that if yer gonna have a namespace, then have one, eg:

    <lc:if a EQ b>
        <lc:set c = d>
    </lc:if>

That’s what having the optional namespace on tags is for: actually specifying one! My impression is that allowing for an empty namespace is one of those things that “just because one can doesn’t mean one should”.

–
Adam

1 Like
3

The “Iris” comitee voted for not having a prefix at all, so the first version was without a prefix, but we learned in real life that not having a prefix makes it very hard to read the code because you have no clear distinction between server and client code. In addition we had some valid concerns that existing tags conflict with existing html tags, we can find ways around known tags, but that is not terministic.

the other parties voted for <ir:, <i: or <r: what would mean for lucee

<lu: or <l: (i think <u: makes no sense)

That is for sure not very sexy

So we decided to go for the shortest version possible (1 character is faster to write than 2).
for me it makes a lot of sense because this are the base/core tags and all tags added with <:import prefix="susi"> then extend that <susi:whatever>.

For some people this maybe looks odd, for me this looks new and fresh. This is not XML, we do not have to care if this is valid in XML or not. CFML/Lucee is far away to be valid XML syntax anyway.

When i started writing C# code I had big troubles because it was feeling very wrong to me, because C# is a copycat from Java but they do things sligthly different what feels wrong.
I’m sure people not familar with CFML think the same about <cfwhatever>, why is this not <cf:whatever>, in that case we do not miss the prefix, we miss the delimiter. But for all of us this is perfectly fine, because we are familar with it for a long time.

3 Likes
4

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

1 Like
5

+1

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

1 Like
6

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.

1 Like
7

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.

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

1 Like
8

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

9

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

10

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
11

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

12

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.

13

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
14

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.

15

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.

16

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>

17

Yes, I actually would be.

18

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.

19

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!

20

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