It's AttributeCollection, not AttributesCollection, ArgumentCollection, nor ArgumentsCollection!
Note: This blog post is from 2007. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.By now I think most have heard of the new AttributeCollection option available for most tags in ColdFusion 8. It's a cool way to dynamically add attributes to a tag.
One problem, though, is that people seem to confuse its name. I've seen it referred to by different names both in current discussions and in older blog entries. Some of the confusion is understandable.
For the record, it's AttributeCollection, not any of the following:
- ArgumentCollection: this is indeed a legitimate attribute for CFINVOKE, when calling a CFC method or UDF instance, or when used similarly calling an instance created by CFOBJECT or createObject.
- ArgumentsCollection: well, this actually was the name of the attribute as of the Beta of CF 8. Ben wrote about it back then, so some confusion could stem simply from people seeing such older entries.
- Arguments: Again, you may well see some blog entry or email list discussion mentioning this, because this what what the attribute was called in the Scorpio Alpha. There was a lot of discussion on blogs pleading that the attribute be named AttributeCollection instead. In fact, Damon Cooper wrote that there were "69 Beta forum message threads about the proper naming of attributeCollection" in his note on Engineering stats for CF8.
- AttributesCollection: and ultimately, it was named AttributeCollection, but since it was for a while called ArgumentsCollection (with the s) it's understandable that some may made the final attribute name plural.
In case anyone's wondering, they may recognize AttributeCollection as not being new as of CF8. In fact, it's not. It was (us) used on the CFMODULE tag to pass in attributes to a custom tag (and also when calling a custom tag as CF_tagname).
For more on using the new attribute, as well as examples of its use, see the CF docs or blog entries by Ben Nadel and Brian Rinaldi. Those also explain where the tag cannot be used (just a small fraction of tags where it really wouldn't make sense, like CFIF, CFSET, and some others) and also how when you use it, you can't use any other attributes.
Hope that clarification above helps someone.
For more content like this from Charlie Arehart:Need more help with problems?
- Signup to get his blog posts by email:
- Follow his blog RSS feed
- View the rest of his blog posts
- View his blog posts on the Adobe CF portal
- If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
- See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
It's further attested to by the fact that in a custom tag, the passed in attributes are accessible in an Attributes scope, whereas in a UDF or CFC method the passed in arguments are accessible in the Arguments scope.
I think it certainly can be confusing sometimes when you have different terminology for the same thing.
If you have a struct of arguments that you're passing to a cffunction, you can just say : myCFC.myfunction(argumentcollection=mystruct)
However, if you're using attributecollection with a cfmail tag, for example, you have to say: attributecollection="#mystruct#"
The difference, of course, being that you have to use the quotes and hash marks with attributecollection. I think the argumentcollection syntax, without the hash marks, makes more sense (since you're not actually outputting the value of the struct), but I guess it just would've been nice for there to be a bit more consistency.
(ha! -- the captcha was "darn")
First, in terms of needing to use pounds and quotes, this really isn't all that different from any other tag (CFML or HTML). With HTML, you can get away with not wrapping a value in quotes, but then the value would be truncated at the first space, which you may not expect. This is because the parser (browser, in this case) needs to delimit the value some way before finding the next attribute.
And there are in fact some tags even in CFML where you can get away with just attr=varname, but the same thing can happen. But usually the engine just prevents you doing it, to avoid confusion (or perhaps just because of unplanned inconsistency).
You don't have that problem when using the key=value pair in a method call (as you showed) because CFML distinguishes arguments by a comma, not a space, therefore you don't need to quote the values and so if one is a variable, you don't need then to put pounds in).
So the difference you note isn't in the attributecollection vs argumentcollection. In fact, if you use argumentcollection as an attribute (rather than as an argument), such as in CFINVOKE, it still requires that it be a quoted string (and therefore pounds as well). So I'm just saying it's not even about the implementation of the new attribute. It's more about just the different between using attributes as function arguments vs tag attributes. Hope that's helpful.
You know, there was something tugging at the back of my brain telling me there was more to it than just a syntactical issue. Thanks for the explanantion.