I think going back to having to check the scope would be a huge step back.
I work at a large bank and on a very large intranet app that is all fusebox
and if we always had to check where a value was coming from...as you point
out...this is what definitely makes formurl2attributes worth it. I could
live without attributes thought...it would be nice to have something you
could traverse like request.xlatvars as a structure or something similar...I
think the overhead would be a little more negligible because it would be a
true structure of pointers to existing variables, thought might get messy if
you had a tone of text. And being request scoped means its available to
everyone and everything for the life of the call then dumped from server
memory.
Anyway, I would agree some changes might be necessary but I would not get
rid of creating a common set of scoped vars from both form. and url. to
expedite reusability.
-----Original Message-----
From: Hal Helms [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 22, 2001 11:13 PM
To: Fusebox
Subject: RE: Musings on Attributes (was Best Pracices...)
Why have a separate scope at all? What's wrong with just using the URL and
form variables as is? That's what I haven't decided on--is having a single
scope worth the hassle?
Hal Helms
Team Allaire
[ See www.halhelms.com <http://www.halhelms.com> for info on training
classes ]
-----Original Message-----
From: Jeff Peters [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 22, 2001 11:03 PM
To: Fusebox
Subject: Musings on Attributes (was Best Pracices...)
Well, after a small bit of tinkering, here are some thoughts:
First, the processing overhead of FormURL2Attributes isn't huge at all. I
created a variable with 80,000 characters in it, and the difference between
processing the page with and without FormURL2Attributes was a grand 2ms.
OTOH, there is the issue of memory on the server, and doing little
experiments
like this does tend to clog that bottleneck. So, I tried this little gem:
------------------- Vars2FBVars.cfm ----------------------
<cfset FBVars = form>
<cfloop collection="#url#" item="var">
<cfset foo = StructInsert(FBVars,var,Evaluate('url.' & var))>
</cfloop>
---------------- End Vars2FBVars.cfm ---------------------
Those who have been bitten by it will remember what happens when you assign
a
variable the contents of a structure, as in line 1: you get pointers
instead
of a copy of the data. It's irritating if you don't want it to happen, but
perfect for what we want here: to change the referent structure without the
overhead of copying the data.
Unfortunately, there's no way (that I've found yet anyway) to make pointers
for
two structures and combine the two structures into one, so we have to make a
copy of the url structure's pairs into the FBVars structure, as in the loop.
This is an acceptable compromise due to the limited nature of a URL--you'll
never get 80,000-character values in there, now will you?
So we end up with a structure, FBVars, that does what Hal wants (combines
all
the url and form variables in a single structure which you can loop over,
and
isn't a fake copy of the attributes scope). The only question left in my
mind
is whether it's worth bringing in genuine attribute-scoped variables as
well.
The only case where you would need this is if you were going to call the app
as
a custom tag, and I think we're finding that case to be quite uncommon.
Thoughts? What say you, Hal?
- Jeff
[EMAIL PROTECTED]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
