Attributes scope vs attributes structure

Question

Custom tags have an attributes scope. Cool.

I've also seen some other apps (and possibly ColdBox?) where the developer put everything into an attributes structure. For example in login.cfm:

<cfparam name="attributes.username" default="some value">

Is there a point to this besides having to specify attributes.foo which does improve readability, I'll admit but why reuse a name of a full scope?

Is this personal preference or am I missing something profound with the attributes scope?

Answer 1

It's nothing profound. A lot of frameworks (and individual developers) like to combine the form and url scopes into a single "event" object or something (ala your "attributes" example), but it doesn't really buy you much.

That said, naming a new object after an existing scope is misguided, and I'd recommend against it. What happens when you want something out of the attributes scope, not the attributes object?

You could always reference the object via variables.attributes.foo for explicitness, but that's a pain and a bit ugly. And of course, nothing stops you from accessing the attributes scope (scope priority would check attributes before variables.attributes), but then the person that has to read the code after you is more confused. It's essentially created a problem instead of solving one.

Answer 2

In Fusebox, the idea was that a individual file could be used as either a part of the framework, or it could be used as part of cfmodule. Inside of corefiles/application.cfc is:

...
<cfparam name="variables.attributes" default="#structNew()#" />
<cfif isDefined("URL")>
    <cfset structAppend(attributes,URL,true) />
</cfif>
<cfif isDefined("form")>
    <cfset structAppend(attributes,form,true) />
</cfif>
...

See GitHub for details