Customize it as you please. I already stick all the circuits.cfm, cf_nesting
and listfirst crud in app_locals, so the index.cfm is back to the original
style of cfincluding app_locals, and then running the switch.
NAT
> -----Original Message-----
> From: Hal Helms [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 28, 2001 6:46 PM
> To: Fusebox
> Subject: RE: Musings on Attributes (was Best Practices...) - in summary
>
>
> I agree about the springs sticking out (so to speak) and am working on a
> cf_fusebox tag that will do a few things to make XFB more accessible for
> everybody.
>
> The problem is that in order to improve what I've done, I would, myself,
> have to reject the idea that my work can't be improved on, a notion that
> appeals to me greatly! Maybe I just better fork over the money
> and go to one
> of my own classes...
>
> 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: Wednesday, March 28, 2001 9:39 PM
> To: Fusebox
> Subject: RE: Musings on Attributes (was Best Practices...) - in summary
>
>
> Okay,
> I'll agree with the genius tag, but I can't really go along with the
> attitude of accepting that Hal's work can't be improved upon
> simply because
> he is an uber-guru. In informal logic, we call this a bad "ad hominem"
> argument, an appeal to authority, the "genetic fallacy", and any number of
> other rude names. This is a dangerous way to go.
>
> On the other hand, as a first guess, we can say that Hal (being Heuristic,
> Algorithmic and Logical) has probably implemented some real
> quality ideas in
> XFB, and we should all consider them long and hard.
>
> In fact, it seems likely to me that XFB in practice does significantly
> reduce the complexity that your average developer has to deal
> with. The XFB
> framework handles all of the trickery for you. At the moment, though, I
> think that too much of XFB's internal workings is exposed directly in the
> index.cfm, where it tends to disconcert/confuse/frighten the child-like
> developer. I'd like this to be hidden away, where practical, in a few
> CustomTags, so that little is left in the index.cfm except the main
> CFSWITCH.
>
> So, has anyone progressed the idea of a <CF_FUSEBOX> tag, which just
> encloses a CFSWITCH, and nothing else? Then we could change our FuseBox
> flavor by dropping in a new CF_FuseBox tag.
>
> Bye now,
> LBB.
>
>
> -----Original Message-----
> From: Hal Helms [mailto:[EMAIL PROTECTED]]
>
> .....
>
> Oh, and I *especially* agree with the part about being a CF genius. ;-)
>
> -----Original Message-----
> From: Nat Papovich [mailto:[EMAIL PROTECTED]]
>
> .....
> This may make you feel like someone is
> trying to hoodwink you, or that you're relying too heavily on an awkwardly
> built house of cards, hoping that is stays together. This is not the case.
> By adopting the nesting portion of Extended Fusebox, you can
> remove yourself
> from the tediousness of the 1's and 0's, and instead rely on a proven
> abstraction, created by a CF genius.
>
> .....
>
>
> IMPORTANT NOTICE:
> This e-mail and any attachment to it is intended only to be read
> or used by
> the named addressee. It is confidential and may contain legally
> privileged
> information. No confidentiality or privilege is waived or lost by any
> mistaken transmission to you. If you receive this e-mail in error, please
> immediately delete it from your system and notify the sender.
> You must not
> disclose, copy or use any part of this e-mail if you are not the intended
> recipient. The RTA is not responsible for any unauthorised alterations to
> this e-mail or attachment to it.
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
