Folks, what about this: we rewrite FormURL2Attributes so that the developer
can decide whether to add form and url vars to the variables scope. Like
this:
<cf_FormURL2Attributes scopeAsVariables = "TRUE | FALSE"> This way, we could
have one tag that would let us all live together in peace and harmony, just
as Rodney King wanted.
Hal Helms
Team Allaire
[ See www.halhelms.com <http://www.halhelms.com> for info on training
classes ]
-----Original Message-----
From: Patrick McElhaney [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 23, 2001 2:48 PM
To: Fusebox
Subject: RE: Musings on Attributes (was Best Practices...)
> Steve asks why the flap over attributes. From my POV, it's that the whole
> thing was so wrong-headed to begin with. It solved a problem that didn't
> exist! It was based on a misperception that form and URL vars weren't
> available to custom tags. And didn't even solve it correctly, as it never
> really made it an attributes scoped variable.
I wasn't around when FB started, so I could be wrong, but I don't think
that's really what the motivation was. I think the motivation was to be
able to pass parameters to a circuit in either the URL or a FORM. Since
the information is coming from the same place, it made sense to merge
the two namespaces into one. And choosing to make the new namespace
"attributes" made it possible use an application as a component of a
larger application. A clever hack, but a hack nonetheless. What they
should have done is just copy everything to the local scope (variables).
Of course Form and URL variables are available to custom tags, but that
kind of violates the custom tags' encapsulation.
> So, the only argument for it is that we want a single-scoped variable. But
> do we only want it for form and URL variables? Why stop there?
Because those are the only parameters explicitly passed to the circuit.
> And of course, there IS a cost associated with it. It does add to
> processing
> time; it does take up server RAM; and it does cause everyone to write
> "attributes." when they aren't strictly needed. Honestly, it bothers my
> sense of clean, elegant code. And my experience has taught me that beauty
> pays off in many ways, many of which can't be immediately predicted.
I agree 100% about the clean, elegant code. Not sure about the RAM,
though. We're only duplicating strings, not large, complex objects like
queries. I'd be surprised if there was more than a 1-2% difference,
overall.
Patrick
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
