I would dearly love to let this thread die, but I don't want you to have the
impression that XFB code is not as reusable as FB code. That really isn't
the case at all. Remember that I came up with XFAs specifically to allow for
code reuse at the fuse level. One reason for nested fuseboxes is to allow us
to continue code reuse --at the circuit or entire application level with a
minimum of fuss. That's why there's so much checking at the fusebox level
about whether this fusebox is in stand-alone or nested. It's to allow for
code reuse without making changes to app_globals, app_locals, etc.
Hal Helms
Team Allaire
[ See www.halhelms.com <http://www.halhelms.com> for info on training
classes ]
-----Original Message-----
From: Nathan Shaw [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 26, 2001 11:17 AM
To: Fusebox
Subject: RE: Musings on Attributes (was Best Practices...)
I have not yet had the chance to work with XFB, but
the biggest problem I *think* I have with it is code
reuse (which was brought up already).
I think the ability to basically drag and drop apps is
sexy as hell, but I am not willing to lose the ability
to call my apps as custom tags/modules just to gain
that. PLUS, using Gabe's App Model and some other
magic =;>, I am tweaking my current fusebox
development style to make it so that plain vanilla
fusebox can have the same drag and drop flexibility.
It seems to me that the differences between using XFB
and Plain FB comes down to the difference between
contractors and full-timers.
Contractors take up one project at a time and, if you
lucky enough to be Hal, you get big-ass projects with
fairly long timelines that require a hell of a lot of
planning and forward-thinking before one line of code
is even written. Therefore, XFB makes a lot of sense.
You plan out the project well, and because it is
planned down to a 'T', you can scope all of your vars
into the variables scope without stepping on toes. The
app you end up with is definitely flexible, but simply
cannot reuse code as easily as basic fusebox can with
its ability to call apps as modules.
Whereas, as a full-timer, I have to work on several
projects at a time where business rules are in
constant flux and the planning stage is often run by
complete idiot Project Managers. I, therefore, try to
save myself work and 'Productize' my apps, making
basic fusebox a more viable option.
This thread has been tremendous in the fact that is
has really brought this factor into light. I think the
solution posed to modify FormURL2Attributes so that
you can stick your vars into whatever scope you like
is an excellent one.
Even though the two methodologies are different, I
really hope we can stay together as a community to
learn and benefit from each other's advances.
Nate Shaw
--- Mike Craig <[EMAIL PROTECTED]> wrote:
> First off, let me say that I have built an extremely
> large intranet site for
> a bank that employed the concept of nesting circuits
> long before XFB came
> out. It was just as possible then as it is now.
> The only difference
> between what I did then and what I would do now is
> employe XFB to handle
> traversing the circuits easier. Now I am working on
> sites at home and using
> only XFB. They are smaller apps to be sure but I
> would have absolutely no
> problem tranlating that intranet site into XFB and
> would love the
> opportunity if they were willing to pay for the time
> (but of course, if it
> ain't broke, don't fix it).
>
> The advantage to XFB seems painfully clear to me the
> first time I need to
> jump from circuit to circuit and when creating a
> circuit for the first time.
> I make the circuit outsite my application and make
> it its own app. Once I
> am happy, I copy the directory structure into the
> app that needs it, tweak
> my circuits file in the application root, remove the
> circuits file from the
> new circuit directory, make my points of entry and I
> am done.
>
> I think the logic of turning:
>
> admin.profiles
>
> into:
>
> myapp.usercontrol.admin.profiles
>
> and intelligently starting at the root of the site,
> collecting what you need
> as you traverse down the tree until ultimately you
> arrive at the "profiles"
> fuseaction is incredibly easy to follow, understand
> and more importantly (at
> least for me) teach. I have taught several people
> how this works and it
> just seems easier than some of the standard
> approaches used in FB 2.0 (as of
> the book printing). Several students have even had
> a "lightbulb" moment.
>
> It IS just another way of looking at how you process
> and if I were not so
> confident that I could do the same thing without XFB
> I would not be saying
> anything, but I have. And Hal...you may not think
> so and perhaps I am just
> too simple a man, but I think this is a very elegant
> approach. XFB does not
> solve everything, but neither does FB...hell neither
> does ColdFusion! (uh
> oh...anarchy).
>
> I'm not sure (as I see some of these discussions)
> how I would want to handle
> calling template routines outside of my home
> application. But realistically
> I probably would not design a large scale site like
> that. I would probably
> have a Home application umbrella that contains
> everything so ultimately you
> would never leave the home app. That is how we did
> it at the bank and it
> made moving entire applications much easier. Most
> apps were driven by
> division/department/group and we found that these
> nebulous entities were
> actually constantly moving. All we ever had to do
> was move the point of
> entry, cut and past the sites directory (under the
> home app no matter what)
> and blam-o (highly technical term) they were fat
> dumb and happy...just the
> way I like my managers.
>
> Anyway, all rambling aside, XFB may not be for
> everyone but I get it, I use
> its technique now, I recommend it now and it
> definitely works for me.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
