ColdFusion 9 CFScript Comments Handle Name-Spaces... And Just About Anything
The other night, I was lying in bed thinking about ColdFusion 9 (hot visual!) when I wondered if ColdFusion 9's new CFScript-based JavaDoc-style commenting would accommodate name-spaced attributes. These have been supported by the CFComponent and CFFunction tags for a long time, but I wasn't sure if the JavaDoc-style commenting would be able to parse the ":" used in the attribute name. As it turns out, ColdFusion 9 will handle name-spaces properly.... and just about any other type of attribute you throw at it.
<cfscript>
/**
* @access public
* @returnType any
* @output false
*
* @kinky:functionType TestFunction
* @123 456
* @ ????
* @> Something
* @# Awesome
**/
function doSomething(){
return( "Hello" );
}
</cfscript>
<!--- Output the function meta data. --->
<cfdump
var="#getMetaData( doSomething )#"
label="doSomething Meta Data"
/>
As you can see above, not only am I trying a name-spaced attribute, I'm trying attributes that either don't make sense (no name - "@") or wouldn't even compile in the tag-based equivalent. And, when we run the code, we get the following output:
I don't have much to say about this - it was just something I wanted to check.
Want to use code from this post? Check out the license.
Reader Comments
It was that very concept that started me down the path of http://hyrule.riaforge.org. Little did I realize that you grab that info in previous versions, but as they say better late than never :)
@Dan,
Being able to use custom attributes is definitely very cool. I was just surprised that it allowed me to do things like set the attribute "123". Although, I guess they aren't *really* attributes at that point - they're just pieces of meta-data.
These all work in annotation-sytle attributes, but some don't work in script-only inline attributes. For example,
/**
* @mxunit:expectedException "myException"
*/
function anMXUnitTest() {}
works, but
function anMXUnitTest() mxunit:expectedException="myException" {}
does not work (throws an error).
Just an FYI.
Good to know Bob, thanks!
@Bob,
Good to know. On a side/related note, I happen to dislike the way inline attributes look post-signature... just seems awkward. I've started to actually like the way the JavaDocs style stuff works - it keeps the function itself simple.
I could not agree more Ben, I think that syntax is really fugly ;)
@Dan,
Right? Before the function, ok (public, return type); but after the method parameters / before the opening bracket... junky!
@Ben and Dan,
We'll just have to agree to disagree about that one, boys ;-)
I understand that they might not look appealing, but I personally abhor the idea of putting code that affects execution into what appears to be a comment. Perhaps I'll come around one day.
When you can show me that the execution is causing performance issues I will listen :) HA..
@Bob, @Dan,
We're a good crowd here:
Dan loves JavaDocs.
Bob says JavaDocs are crazy.
Ben says, it's all moot since TAGS are where it's at :)
I am going to buy the following domain and point it to your website Ben. HA ;)
http://www.tagsareforui.com
@Dan,
Ha ha ha, awesome :) Tags FTW!
I was thinking maybe if we could use it just like javadoc someone would even build a plugin for Eclipse called CFDoc. That would be rad.
I agree with Bob. I don't like the idea to mixing code with comment! Just doesn't seem right. Also, I'm scared that a noob may look at it as comment and remove it :)...
awesome... grreeeeeeaaaattt :)