I guess I thought that "attributes." was created to be the unified
interface for variables being passed to a fuseaction and the individual
act_, qry_ & dsp_ files included. That is important to me for the
reasons that others have mentioned. I like that individual fuseactions
are encapsulated from each other via the "attributes." scope (or
mechanism if that's more appropriate. I want to be able to call a
fuseaction in the manner that works best for particular need and know
that it will work.
I can't say, however, that I know anything about the phenomenon that is
"xfa" and how it is different from the simple 'caveman' fusebox that I
use.
Kevin
> -----Original Message-----
> From: Hal Helms [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 23, 2001 1:37 PM
> To: Fusebox
> Subject: RE: Musings on Attributes (was Best Practices...)
>
>
> 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
