I think that I'll chime in on the subject of "extended" fusebox or "nested
fuseboxes." XFB solves one major hurdle that fusebox out of the "box" does
not really solve, and that is large team development projects. With XFB, it
is easier to break out large projects in nice sized blocks for developers to
work on. It frees developers from several bottle necks that can come up in
large teams developing code simultaneously. A developer can work on their
sub application in an autonomous fashion, that is then is glued together by
the system architect that is heading up the project.
My past experience with normal fusebox is that is solves a lot of problems.
However when you start having development teams of 10+ developers working on
building out an application, it introduces a lot of inefficientes in the
process of building. I have also found code built with extended fusebox to
be far more reusable that normal fusebox. The main reason, is that the code
truely does become plug and play.
One of the things that I have been working on of late is to use extended
fusebox as the basis of an application framework. The results are great. I
have become ~20% more efficient in building solutions with extended fusebox
over traditional fusebox, mostly because I am for the first time truely
getting reuse from code.
Thanks,
David Sparkman
Application Development Team Leader
Weberize
http://www.weberize.com
-----Original Message-----
From: Steve Nelson [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 23, 2001 1:00 PM
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
