The solution is to rewrite the tag so that it can be placed wherever:
attributes, variables, args, etc. This lets people develop in the way they
feel most comfortable with.
Hal Helms
Team Allaire
[ See www.halhelms.com <http://www.halhelms.com> for info on training
classes ]
-----Original Message-----
From: BORKMAN Lee [mailto:[EMAIL PROTECTED]]
Sent: Saturday, March 24, 2001 8:05 PM
To: Fusebox
Subject: RE: Musings on Attributes (was Best Practices...)
Now this sounds like a reasonable idea, as it would keep the ARGS away
from the VARS, except it will involve a larger perfromance hit, because
it has to copy THREE scopes into one, not just just two. The
advantages, though, are:
1) Proper CF structure that can be looped, etc;
2) Shorter prefix?
Is that right?
LBB
-----Original Message-----
From: Peter Theobald
To: Fusebox
Sent: 3/25/01 9:17 AM
Subject: RE: Musings on Attributes (was Best Practices...)
I don't see any downside to putting all FORM, URL, and ATTRIBUTE
variables into a structure.
For example, FORMURLATT2ARGS copies to a structure named 'ARGS'.
All incoming arguments are in one place.
It can be looped over.
You can tell the difference between arguments and regular variables.
'ARGS' is even less typing than ATTRIBUTES :-)
?
At 04:16 PM 3/23/01 -0500, Hal Helms wrote:
>Steve, would you be cool with adding form and URL vars to the variables
>scope instead of the attributes scope? That would solve all my issues.
>
>Hal Helms
>Team Allaire
>[ See www.halhelms.com <http://www.halhelms.com> for info on training
>classes ]
>
>
>-----Original Message-----
>From: Steve Nelson [mailto:[EMAIL PROTECTED]]
>Sent: Friday, March 23, 2001 2:22 PM
>To: Fusebox
>Subject: Re: Musings on Attributes (was Best Practices...)
>
>
>That's NOT why we didn't use form and URL!!!!! It was put in there for
>this reason:
>------------------------------------
><cfquery datasource="blah">
> insert into sometable(somefield)
> values(#attributes.somefield#)
></cfquery>
>------------------------------------
>you can now call that code like this:
>------------------------------------
><cfmodule template="/blah/blah/index.cfm"
> fuseaction="addwhatever"
> somefield="stinky stinky cheese">
>------------------------------------
>NO FORM IS NECESSARY! If you use the form scope, you're tied to the
>form on the previous page. Which means you lose a ton of flexibility.
>
>Try doing it with a form scope.
>------------------------------------
><cfquery datasource="blah">
> insert into sometable(somefield)
> values(#form.somefield#)
></cfquery>
>------------------------------------
><cfmodule template="/blah/blah/index.cfm"
> fuseaction="addwhatever">
>------------------------------------
>This won't work! You would need the form, or you need to be super
>kludge with your code to make it work.
>
>Steve "wikitiwak" Nelson
>
>Hal Helms wrote:
>>
>> Oh yeah? Yeah? You and what army, pal?
>>
>> 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.
>>
>> 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? In
other
>> words, I don't see the rationale behind it. I think that we look at
the
>> ancillary benefits (putting unrelated code in the tag that parses
search
>> engine friendly URLs), but that has nothing to do with creating new
>> variables with an "attributes." as part of their name.
>>
>> 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.
>>
>> Hal Helms
>> Team Allaire
>> [ See www.halhelms.com <http://www.halhelms.com> for info on
training
>> classes ]
>>
>> -----Original Message-----
>> From: Nat Papovich [mailto:[EMAIL PROTECTED]]
>> Sent: Friday, March 23, 2001 11:52 AM
>> To: Fusebox
>> Subject: RE: Musings on Attributes (was Best Practices...)
>>
>> Well the stinking tag is called FORMURL2attributes, not
>ALLVARS2attributes.
>> So I like the flexibility of having my form and url vars in attribs,
but
>> don't really care about my xfa vars. Using your rationale, it would
seem
>> that every var you ever use would be attributes, which I know is not
>right.
>> I just make a decision to only scope certain things certain ways.
>>
>> NAT
>>
>> > -----Original Message-----
>> > From: Hal Helms [mailto:[EMAIL PROTECTED]]
>> > Sent: Friday, March 23, 2001 5:29 AM
>> > To: Fusebox
>> > Subject: RE: Musings on Attributes (was Best Practices...)
>> >
>> >
>> > The reason I put XFAs in the attribs scope is that I was trying to
be
>> > consistent with the whole FormURL2Attributes logic, the argument
>> > being that
>> > we should have a unified scope. So now, you're going to have some
>> > vars that
>> > are purely local and some that are attributes? These attributes
>> > are starting
>> > to feel like an appendix--having had a purpose at one time, but now
just
>> > hanging around.
>> >
>> > When do I get to see my little um...err...clone/baby?
>> >
>> > Hal Helms
>> > Team Allaire
>> > [ See www.halhelms.com <http://www.halhelms.com> for info on
training
>> > classes ]
>> >
>> >
>> > -----Original Message-----
>> > From: Nat Papovich [mailto:[EMAIL PROTECTED]]
>> > Sent: Friday, March 23, 2001 2:13 AM
>> > To: Fusebox
>> > Subject: RE: Musings on Attributes (was Best Practices...)
>> >
>> >
>> > What do XFBs have to do with the attribs scope? I never put them in
the
>> > attribs scope myself, only the local scope (and not as a structure
as
>the
>> > original XFB outline mentions), and I haven't gotten a ticket
yet...
>> >
>> > NAT
>> >
>> > p.s. The creation (birth?) of Mini Hal is coming along nicely.
>> >
>> > > -----Original Message-----
>> > > From: Hal Helms [mailto:[EMAIL PROTECTED]]
>> > > Sent: Thursday, March 22, 2001 9:54 PM
>> > > To: Fusebox
>> > > Subject: RE: Musings on Attributes (was Best Practices...)
>> > >
>> > >
>> > > John,
>> > >
>> > > Part of the cost is having to prefix everything with
"attributes."
>When
>> > > dealing with XFAs, etc, this gets to be a significant amount of
>> > > time. But I
>> > > agree with you about the search-engine friendly URLs. That's a
>> > > nice feature.
>> > > Score one for FormURL2Attributes.
>> > >
>> > > Hal Helms
>> > > Team Allaire
>> > > [ See www.halhelms.com <http://www.halhelms.com> for info on
training
>> > > classes ]
>> > >
>> > >
>> > > -----Original Message-----
>> > > From: John Quarto-vonTivadar [mailto:[EMAIL PROTECTED]]
>> > > Sent: Friday, March 23, 2001 12:01 AM
>> > > To: Fusebox
>> > > Subject: Re: Musings on Attributes (was Best Practices...)
>> > >
>> > >
>> > >
>> > > > I agree--that's the only thing that's really nice about having
>> > > it. Again,
>> > > I
>> > > > just wonder if the cost is worth it.
>> > > >
>> > >
>> > >
>> > > somehow I missed the originating comment that must have started
>> > this. Has
>> > > someone done a cost analysis to see exactly how much we are
>> > really paying
>> > > for the convenience?
>> > >
>> > > (as an aside, if the need for ATTRIBUTES is somewhat moot due to
non
>FB
>> > > custom tag calls, and therefore only FORM and URL are in play,
>> > > then perhaps
>> > > we should need a URL2FORM.cfm or vice-versa tag. I happen to like
the
>> > > ability to have search-engine friendly URLs)
>> > >
>>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
