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