How about <cf_formurl2x> then?
You can always set a keystoke in Studio to insert attributes.
---
Jeffrey B. Marsh
Professionals built the Titanic.
Amateurs built the Ark.
-----Original Message-----
From: Patrick McElhaney [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 23, 2001 10:06 AM
To: Fusebox
Subject: RE: Musings on Attributes (was Best Practices...)
>
> That loses the advantage of search engine safe URLs and makes custom
> tags harder to deal with.
No, read it again. I'm not talking about getting rid of
CF_FormURL2Attributes. I'm talking about eliminating the need for
the attributes scope.
> Let me bring up the question again.... What problem are we trying to
> solve?
>
> Is <cf_formurl2attributes> processing too slow?
No.
> Is "attributes." to hard to type?
It's a minor irritation to type. It's also a minor irritation to have
to horizontally scroll sometimes because we have 11 extra characters
for each variable. And it makes the code less concise. And when these
little things are compounded anywhere from a few dozen to several
hundred times per circuit, it becomes a real problem.
> Does the attributes scope break something?
It's a hack.
> Are we bored?
No.
> Patrick McElhaney wrote:
> >
> > I've put a lot of thought into it, and have come to the conclusion
> > that we don't need attributes.
> >
> > The idea behind "attributes" is this: We combine all of the scopes
> > into one so we don't have to specify the scope a variable originated
> > from. But that's no big deal, because Cold Fusion does that anyway.
> >
> > If you leave out the scope, CF checks all of the following scopes in
> > the specified order:
> > 1. Local variables created using CFSET and CFQUERY
> > 2. CGI variables
> > 3. File variables
> > 4. URL variables
> > 5. Form variables
> > 6. Cookie variables
> > 7. Client variables
> >
> > The only problem I see with this is if you want to use fusebox as a
> > custom tag, you can only access the parameters passed through the
> > attributes scope. The designers of Fusebox decided to tackle this
> > problem by putting *everything* in the attributes scope, whether
> > the circuit is being called as a custom tag or not.
> >
> > It seems to me that it would be easier to go the opposite direction,
> > by copying all attributes scoped variables to locally scoped
> > variables. But then you run into encapsulation problems. Local
> > variables in the calling template aren't available to custom tags,
> > but URL & FORM variables are. Still not a major problem because
> > FORM and URL variables will never override a variable scoped
> > locally within a custom tag.
> >
> > The only problem is if I want to check for the existence of a
> > local variable. The variable may be present in the form scope, but
> > not the local scope, causing my isDefined("") function returns true
> > where I expect it to be false. The same problem happens with CFPARAM.
> >
> > However, I've done some reasearch and found a workaround for that.
> > Cold Fusion has a default scope for local variables (called "Variables")
> > and that's the first scope in the list that it checks. So if I
> > write <cfset x = 1>, CF interprets that as <cfset varibables.x = 1>.
> > And I can verify that a variable exists in the local scope by
> > checking 'variables.x' instead of just 'x'.
> >
> > In order to make this work properly, we would need to make sure all of
> > our FROM, URL, and ATTRIBUTES variables are copied to the "variables"
> > scope (CF_FormURL2Variables?), but we could leave off the scope when
> > referring to our variables, except when we are checking for their
> > existence.
> >
> > Patrick
> >
> >
> >
> > 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
