Hi Luis and ColdBox Team
I posted to Taffy mail list about this Railo ticket I have opened and Adam said you have raised same issue with Adobe - which seems to be resolved
https://issues.jboss.org/browse/RAILO-3092
Please vote / add comments if you think it would be useful for your framework.
Honestly, I think I agree with Micha that it shouldn’t be supported. The problem is that “:” is a special character that separates names and values just like “=”. I think it would equally wrong to put in a ticket saying you wanted to be able to have an equals sign in an attribute value.
For instance the following are both supported as equivalent:
var x = {
foo = ‘bar’,
doo = ‘baz’
};
var x = {
foo : ‘bar’,
doo : ‘baz’
};
A colon or an equals sign can separate name/value pairs.
Therefore, I would expect all of these to throw parsing errors:
component foo=bar=baz {}
component foo:bar:baz {}
component foo:bar=baz {}
component foo=bar:baz {}
It’s impossible to know which part is the name and which part is the value.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
attributes are separated by whitespace
attributes are name value pairs
var1 = 123
I don’t think you can have
component foo var1 : 123 {}
Framework authors have been using colons to namespace attributes
component foo ajm:var1 = 123 {}
The following are acceptable to Railo Script
component foo ajm-var1 = 123 {}
component foo ajm_var1 = 123 {}
Colon in attribute names are supported in TAGs
attributes are separated by whitespace
Correct, I wasn’t saying otherwise.
attributes are name value pairs
var1 = 123
Your example is correct, but incomplete, as CFML also allows a colon to separate a name/value pair.
var1 : 123
I don’t think you can have
component foo var1 : 123 {}
No, but you can have this:
function test() foo:“bar” {}
Honestly, I think the fact that the colon doesn’t work in the component declaration is a half-implemented oversight and bug. It should work in my opinion.
Framework authors have been using colons to namespace attributes
component foo ajm:var1 = 123 {}
Sure, but it doesn’t make it right. I don’t think colons have ever been valid in variable names. Back in the day, name/value pairs always used equals signs so it didn’t matter. CFML has changed though and now colons have more reserved meaning so the original rules are being enforced more tightly.
The following are acceptable to Railo Script
component foo ajm-var1 = 123 {}
component foo ajm_var1 = 123 {}
The hyphen might be technically invalid, but since underscores and hyphens aren’t special characters when defining a name, value pair I am not surprised by that behavior.
Colon in attribute names are supported in TAGs
I have feeling that is more because colon support is a bit half baked, not for any particularly good reason. If anything, I’d say tags are operating incorrectly and should match script. It doesn’t help that Adobe CF has two separate parsers-- one for tags and one for script.
What makes it even worse is that neither Adobe CF nor Railo have any real documentation (that I can find) that fully explains what is valid and where. That leaves us guessing whether the inconsistencies are on purpose or just leftovers of half-implemented syntax. I would be inclined to push that if CFML allows colons to separate name/value pairs, it should do it consistently everywhere in the language. And therefore, colons would always be invalid in every scenario unless you were able to somehow escape them.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
we might be talking cross purposes here
component foo ajm:var1 = 123 {}
is not ajm = var1 = 123
ajm:var1 is the attribute name - like
ATTRIBUTES[‘ajm:var1’] = 123
This is to namespace attributes, so if the situation ever occurred, you could have
component foo ajm:var1 = 123 coldbox:var1 = ‘xyz’ {}
Oh, I understand how you interpret the code. The issue, is how would the CFML engine’s syntax parser know that? If a colon and an equals both separate name/value pairs (or should at least) then there is no difference between ajm:var1=123 and ajm=var1=123 or ajm:var1:123 The difference would only exist in your head because you knew what you meant when you typed the code.
Also note, CFML is not XML and namespaces do not exist. The closest we come is when you can prefix a custom tag, but that doesn’t apply to the attributes of the tag.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
I am not sure where there would ever be a situation where you have
component foo ajm=var1=123 {}
or
component foo ajm:var1:123 {}
or (for completeness sake)
remote any function getProfile()
ajm=var1=123 {}
ajm:var2:123 {}
{}
Exactly. That’s why I disagree with what you want because that’s what you’re essentially doing now that CFML is starting to use equals and colon interchangeably for name/value pairs.
function getProfile() ajm:var1=123 {}
is parsed the same as
function getProfile() ajm=var1=123 {}
and I don’t think either of those should be valid.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
but you cannot add any attributes with colon for assignment
eg
AJ I agree with Brad, this was added in CFML tags prior to the take off with cfscript.
What Brad has been trying to say is that ColdFusion would not be able to do this and I would be surprised if Railo did too.
component restpath="/securities" rest=“true” rest:isSecure:true {}
Because as Brad stated the colon can be used in place of the equals sign, if Railo supports that and then can identify which is an attribute and what is not.
maybe the code should be wrapped like
component restpath : “/securities” rest : “true” ‘rest:isSecure’ : true {}
This is one thing that mxUnit allowed in cftags, but was never possible to do as ColdFusion Script would not allow colons that mxUnit would/could use to do error exception handling.
This is what I don’t understand - using colon to assign a value on attributes for a component or function
This throws an error on Railo
Railo 4.2.1.003 Error (template)
Message Invalid Identifier, the following character cannot be part of a identifier [:]
Stacktrace The Error Occurred in
C:\websites\railo-express-4.2-websocket\api\tradecentre\securities.cfc: line 1
1: component restpath : “/securities” rest : “true” {
2: //component restpath="/securities" rest=“true” rest:isSecure=true {
Does it work on ACF11?
Yes, we covered this earlier. I personally think those behaviors are incorrect. Inconsistencies at best, bugs at worst. And therefore, I don’t think they’re good justifications.
Adobe and Railo have begun the precedent that colons also separate name/value pairs and they need to work everywhere.
Note, according to Micha, a variable assignment is not the same as a name declaration. Dig about 3/4ths of the way down this thread to read his explanation of why “assignment” is the wrong term: https://groups.google.com/d/topic/railo/yBOZxJ4x_Wk/discussion
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
It actually does work for functions. This runs on Railo and creates an attribute called “foo” with a value of “bar”
function test() foo:“bar” {}
It doesn’t work on components for the same reason it doesn’t work on tags. You may not know this, but component {} is actually considered a tag in Railo. It falls under the same umbrella as
lock {}
pop {}
document {}
etc…
Basically, take any tag, remove the brackets, end tag, and “cf” and add {} to denote the “body” of the tag.
becomes
component {}
Functions work because they aren’t just carry-overs from tags, the function syntax is a first class citizen of script.
The reason why Micha hasn’t ever allowed colons in components is probably because he’d have to allow them in all tags. I’m actually tempted to put in a ticket to see what he says, but I don’t know that he would actually fix the inconsistency because it would break stuff like MXUnit that has been “cheating” and using colons because they could get away with it all these years.
Honestly, it’s a bit of a catch 22. Continuing to allow colons in attribute names just adds more inconsistency and confusing elements to the language, but fixing it all to actually be consistent across the board would break legacy code.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
This should be good. I can’t wait to hear what Micha says…
https://issues.jboss.org/browse/RAILO-3167
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
I think your argument that function metadata should not support colons in the attribute names because they currently support colons for assignment in function attributes is not the best reason.
I don’t have CF11 installed, so I’m testing on CF10, but my testing on CF10 shows that ACF does not support colons for function metadata assignment, as in:
<cffunction name=“foo” colon:“colonified”>
So if Railo supports this, it is different from ACF. ACF also supports this syntax:
And according to the bug tracker, at least in CF11 (possibly being back-ported to CF10), this is supported (I have not checked):
// WORKS:
function foo() colon:foo=“colonified” {}
So if Railo choose not to support this syntax, it will be (yet another?) deviation from ACF.
You also say that in CFML namespaces “don’t exist.” Just because we don’t have a WSDL doesn’t mean namespaces don’t exist. Perhaps “namespace” is a bit of a misnomer, maybe “prefix” would be more reasonable. (We could argue the finer points of that, but in the end it doesn’t really matter what you call it.) Their reason for existing (and they do exist) is to allow framework developers to use reasonable variable names without fear of collision with another framework or a future core-language feature. For example, should CFML add a “URI” attribute for REST (or some other functionality) support, there is no danger of a collision with Taffy because it uses “taffy:uri” and “taffy_uri” (both are supported because of the aforementioned bug in CFScript).
Prefixing is clearly a good idea. And if colon is an available character, I think it makes a lot of sense to use it. Adobe seems to agree that it’s a reasonable addition, because they support it for tags and are fixing (have fixed?) it for script.
The only reasonable explanation I’ve seen so far has been your explanation of why it doesn’t work for tags/component{}, but does work for functions… That explains why things work the way they do, but I still don’t think it’s a good reason not to support this functionality. The argument essentially becomes, “it’s hard” or “it would make the code messy” (to add in exceptions to the general rule of how things work currently). Neither of which are valid arguments, in my opinion. It’s a consequence of the choice to implement script as a general solution to drop the angle brackets from tags; combined with the consequence of supporting colons for assignment anywhere outside of structures and function-execution argument lists, which as far as I can tell, are the only two places that ACF supports them. Basically: you’ve made your bed, now you’re complaining about sleeping in it.
Adam
After posting this I realized that I was on the Coldbox list, not the Railo list (hence the bit about making “your” bed and sleeping in it)… So obviously that’s only directed at any fervent supporters of the path Railo have chosen. 
Adam