Yep, the reason I was able to get RoomsToGo Kids up so quickly was the
ability to reuse code--not as in cut and paste, but as in treating the
entire RTG site, which until then had been a standalone app, as a nested
fusebox in a SUPER site which worked with both RTG and RTG Kids. Later, when
they decide to build some other RTG sites, we'll make those nested fuseboxes
of the super site. Maybe at some distant point, the super site will itself
become a child of a super super site...
I understand that it's hard to really see this if you haven't worked with it
on large sites in the real world, but it really is a pretty wonderful thing
to drag and drop an entire application, with virtually no changes to the
code. You've heard from people (including me) who have built some very large
applications with XFB and have been pleased with the simplicity and
coherence of the approach. For some, though, XFB won't appeal and I'm not
trying to win converts. For instance, I find Fusedocs and XFAs absolutely
integral to writing robust, scalable, reusable and maintainable code. But
some people don't like them--just as some people don't like Fusebox in any
flavor. I wish them ALL the best; I just wanna write great code.
Hal Helms
Team Allaire
[ See www.halhelms.com <http://www.halhelms.com> for info on training
classes ]
-----Original Message-----
From: Steve Nelson [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 26, 2001 10:34 AM
To: Fusebox
Subject: Re: reusing circuits (was Musings on Attributes)
I agree completely with your statement about reuse among different
companies/sites can be separate wild animals.
BUT... think about the reuse from within the same site.
Example:
Look at these URLs:
http://www.secretagents.com/help/index.cfm?fuseaction=answerform&question_id
=5
http://www.secretagents.com/stats/reports/index.cfm?fuseaction=sitestats
http://www.secretagents.com/stats/reports/index.cfm?fuseaction=browserreport
If you try to go to any of them, you'll see that they ALL will kick you
over to the "fuseaction=loginform" in the "/members" circuit. That is
because you need to be logged in with correct permissions to view the
pages.
I'm not reusing this across multiple sites (i.e. all of these circuits
are within secretagents.com), but I am reusing them across multiple
circuits within the same site.
(This uses the <cf_returnfuseaction> tag with the
app_secure.cfm/app_login.cfm/app_logout.cfm files, which I'll post one
of these days)
Steve Nelson
Try my CFML code tester for free!
http://www.secretagents.com/tools/stomp/
(804) 825-6093
Hal Helms wrote:
>
> Dear Mr. Fermat,
>
> I hear what you're saying about using circuits as objects. Have you
actually
> found this to be workable in real-world situations? What I've found is
that,
> for example, security module for application A at company XYZ is a
> completely separate animal from the security module for application B at
> company XYZ. They don't use the same databases, don't run on the same
> servers, etc. They are, for all intents and purposes as separate as if
they
> were being deployed for separate companies. There are all sorts of reasons
> for this--some of them technical; others political, but they exist. This
> being the case, having a central instance (single location) of a security
> object is neither feasible nor desirable.
>
> On the other hand, the code for both these modules may be exactly the
same,
> so the kind of reuse that I'm talking about is from the developer's POV.
> I've written this security (or whatever) module for application A for
> company XYZ; Now I need another security module for application B for
> company ABC. I may not be able to have a single runtime module that
handles
> all applications for a single company (just as I can't have a single
> application that handles everything), but I can reuse the code for this.
In
> other words, the reuse occurs at design time and not at run time.
>
> On the other hand, I agree with your criticism of every circuit having to
> keep track of the circuits beneath it. I originally was going to have the
> code walk the directory structure, etc, but the overhead seemed
outrageous.
> However, I've always thought this was a kludge. It's not terribly onerous
to
> implement, but its inelegance bothers me and I would like to see a better
> way to implement the idea. As I said in the discussion on
> FormURL2Attributes, I do believe that code that isn't beautiful isn't
good.
> And this isn't beautiful.
>
> So now, that the theorem of your ancestor has finally been solved, would
you
> care to use the margin of this email to jot down a mo' better
> implementation?
>
> 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: Sunday, March 25, 2001 10:10 PM
> To: Fusebox
> Subject: RE: Musings on Attributes (was Best Practices...)
>
> I'm puzzled about how XFB promotes code re-use above and beyond "normal"
FB.
> Probably my concerns will be answered when I get over there to attend one
of
> Hal's courses.
>
> As I understand it, with XFB, you "re-use" code (eg., a login routine) by
> making a copy, and placing it under the new application's tree. Is that
> correct? If that's so, then it's only a very primitive form of re-use.
> Making separate clones of the code you wish to re-use, and distributing
all
> of these copies throughout your applications does not amount to
substantial
> re-use. What happens when you want to enhance your login routine? Do you
> then have multiple versions lying around, all out-of-synch? Surely the
goal
> is to have one single login routine, in one single location, and to CALL
it
> from each of your multiple applications.
>
> Using "normal" FB, substantial re-use is accomplished simply by means of
> CFMODULE, or by the CF_ReturnFuseAction tag, depending on the situation.
> How is this done under XFB? I'm sure it can be done, but the
documentation
> I have read concentrates on "nesting" of component applications. True
> nesting is incompatible with single-location code re-use. After all, a
> single piece of code simply CAN'T be nested under multiple trees - it has
to
> be COPIED (unless you are using symbolic links to fudge it). I have
> discovered an ingenious proof of this, but unfortunately I don't have room
> here in the margin to write it all down... In other words, nesting
> circuit-applications make sense in terms of breaking down and organising
an
> application, but it has little relevance for code re-use, which (as Hal
has
> often told us) is surely the holy grail of programming.
>
> I believe that XFB can be altered somewhat to allow "nested" circuits that
> actually reside outside the home circuit's tree. XFB uses circuits.cfm to
> register the existence and location of circuit applications WITHIN the
> current application tree - I think this technique could be modified to
allow
> the circuits to reside ANYWHERE in the web-tree.
>
> I also have some concerns about the need to register a low level circuit
in
> each and every ancestor's circuits.cfm. I'd like to see inheritance of
> circuit definitions moving from descendants back up through their
ancestors.
> So each level of the application would only need to be told about its
direct
> children, but could find out about it's grandchildren, great-children,
etc,
> indirectly.
>
> If that were done, then XFB would have real re-use, as well as the XFB
> advantages of inherited variables, etc. Furthermore, redundant/duplicate
> definitions in circuits.cfm files would be remedied.
>
> Thanks all if you're listening...
>
> Bjork
>
> -----Original Message-----
> From: David Sparkman [mailto:[EMAIL PROTECTED]]
>
> 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.
>
> 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
