I know I'm coming in late on this discussion, but I recently just got my
head around XFB's. I don't know that "what does it solve" is necessarily
the right way to look at it. At the end of the day, I didn't employ nested
circuits etc because they gave me any abilities that the core fusebox model
didn't - but because the idea appealed to me. One certain thing it did was
do away with a hell of a lot or url_ files. I was previously directing all
traffic back to the home app, as per usual, which, considering I have about
30-40 circuit apps on top, leads to a lot of url files.
using nested circuits - and predominantly the circuits.cfm idea changed that
quite a bit. It allows me to make a direct reference to a fuseaction in
another circuit, without actually making my code any less modular. Because
the circuits inherit the myglobals from the home app - and everything points
to #self# regardless of whether it's the home app or not, it means that you
just change your circuits.cfm and everything's rosy. You kinda get
hard-coded direct urls without hardcoding. I know that doesn't really make
any sense but that's how I felt.
Apart from all that, to re(over)use/rehash the phrase that's been floating
around - it made things nice and orderly for me.
Regardless of the above - I find nested circuitry to be something that makes
sense to me programatically - and it realigns my thinking along paths I
might not ordinarily have traveled. That in itself, for me at least, is
enough of a reason to continue using it. It's exactly the same reason I
picked up fusebox in the first place...
So maybe for some people it does present a programmatical advantage, but
perhaps it's more of a "this really does make sense to me and makes my code
a lot cleaner" kind of thing. Which is good.
Raising the question, is it a bad thing to present a fusebox methodology
with a core fundamental, then built on and translated into two different
interpretations?
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: Steve Nelson [mailto:[EMAIL PROTECTED]]
Sent: Saturday, 24 March 2001 6:00 AM
To: Fusebox
Subject: Re: Musings on Attributes (was Best Practices...)
Everything you just said was the reason fusebox was created in the first
place. My Fusebox sites aren't using the XFB version of nested fuseboxes
yet I would say the exact same thing about them as you did below.
Understand I'm only questioning the need for nested fuseboxes... not
fusedocs, exit fuseactions, test harnesses etc, those ideas are great
and solve very distinct problems.
I just want to understand what problem is solved with the XFB version of
nested fuseboxes. That's all.
Steve Nelson
Strange Tactics wrote:
>
> Well its not a programatic reason but I use xfb because I love the
> organization, looking at a site from its root directory I like to have
> code, graphics, scripts etc all in their places (separate dirs). When I
dig
> into the site to fix/add one thing or another my choices are clear and
> navigating to a point in the site at the file level is easy. Bear in mind
> that I have all my circuits in a /circuits dir for more separation, xfb
> allowed me to do that. Its a simplistic reason but xfb adds order to my
> world. Self contained circuits are also practically drag and drop from one
> site to the next, I love that too. To be fair I haven't really explored
the
> base Fusebox to see if these are legitimate reasons but once I grasped xfb
I
> felt that it made sense.
>
> Shane Johnson
> www.strangetactics.com
> [EMAIL PROTECTED]
> Coldfusion developer
> Fusebox compliant (XFB)
>
> -----Original Message-----
> From: Steve Nelson [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 23, 2001 6:57 AM
> To: Fusebox
> Subject: Re: Musings on Attributes (was Best Practices...)
>
> The Attributes scope solves 3 problems with utter simplicity.
>
> 1) Make form, url, and attributes into a single scope so switching
> between the scopes doesn't change code
> 2) They allow for search engine safe urls without changing code
> 3) They allow for calling an index.cfm as a cfmodule (simple nesting)
>
> I have to be honest here... I'm not convinced of the nested Fuseboxes.
> I've tried it a few times now just to play around with them and I find
> that it adds a huge layer of complexity to the ultra simple concept of
> Fusebox. I still have not heard an argument for what problem nesting
> Fuseboxes actually solves. Sure the concept is cool, but I'm just not
> seeing the need for it.
>
> Can anyone show us a real life example of where nested Fusebox solved
> something that couldn't be done with a simple cfmodule call to an
> index.cfm file? I'd be happy to show a couple real life examples of
> simple cfmodule call to an index.cfm file.
>
> Steve Nelson
> Try my CFML code tester for free!
> http://www.secretagents.com/tools/stomp/
> (804) 825-6093
>
> Hal Helms wrote:
> >
> > 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
