so what happens to the conflict between previous locally scoped variables
and the new ones (form url and attr)? Up to now, it doesn't bother me
because I know I can have a local var named whatever I like, because
everything coming in (whether the app is a standalone circuit or nested with
others) is in a different scope...
I wouldn't like to be forced to anticipate that kind of thing when I'm
coding.
Toby Tremayne
Code Poet and Zen Master of the Heavy Sleep
Show Ads Interactive
359 Plummer St
Port Melbourne
VIC 3207
P +61 3 9245 1247
F +61 3 9646 9814
ICQ UIN 13107913
-----Original Message-----
From: Hal Helms [mailto:[EMAIL PROTECTED]]
Sent: Saturday, 24 March 2001 7:55 AM
To: Fusebox
Subject: RE: Musings on Attributes (was Best Practices...)
That's why I think putting them in the variables scope makes perfect sense.
No need to put them in a scope they really don't belong in. Again, I'm not
suggesting this for basic Fusebox; I'm really thinking in terms of XFB.
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:10 PM
To: Fusebox
Subject: RE: Musings on Attributes (was Best Practices...)
You want aesthetics? Stick them in a real attributes scope if you don't like
faking a scope. Then you can loop over them and do structcount and
structfind and all kinds of goofy things (which could just as easily be
accomplished using other functions not starting with "struct"). I know Hal
and Jeff are constantly finding reasons to loop over their attributes
scope...
And about the folks who complain about the extra letters to type - have you
ever heard of snippets mapped to shortcut keys? Writing emails is about the
only time I use any single keystrokes. You gotta be like one of those court
stenographers with your coding. Extra typing is a non-issue when compared to
not scoping variables at all, and letting CF do it's own ordering (which is
a mr. yuck idea).
NAT
p.s. Mini Hal is breathing off a respirator now - still unconscious, but
will soon be awakening. And for the record - this is not my first clone-job.
> -----Original Message-----
> From: Hal Helms [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 23, 2001 10:31 AM
> To: Fusebox
> Subject: RE: Musings on Attributes (was Best Practices...)
>
>
> Exactly put, Jeff. When I originally said I was ready to deep six
> attributes, it was out of frustration that we have this thing that is
> undoubtedly useful but ugly as sin.
>
> 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: Friday, March 23, 2001 12:47 PM
> To: Fusebox
> Subject: Re: Musings on Attributes (was Best Practices...)
>
>
> On 23 Mar 2001, at 11:04, Steve Nelson wrote:
>
> > Let me bring up the question again.... What problem are we trying to
> > solve?
>
> My tests tell me there's no real performance hit with
> formurl2attributes, so
> I
> see the problem in two parts:
>
> 1. The "attributes" scope as generated by formurl2attributes isn't the
> Attributes scope, so you can't do loop operations over an attributes
> structure
> and see all form, url, and attributes variables.
>
> 2. Formurl2attributes creates copies of form and url variables, thus
> doubling
> the server memory used for those scopes in Fusebox apps. I'd much rather
> see a
> means to use a structure of pointers that would cover form-, url-, and
> attributes-scoped variables. This would accomplish the same
> goals as using
> the
> current approach, while streamlining memory use and providing a complete
> structure for accessing variables "passed into" a Fusebox module.
>
> That's the problem I'd like to solve. It's not a showstopper, but it has
> important implications.
>
> - Jeff
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
