Good. I'm glad you're doing it that way and not duplicating
directories..... But, now I'm thoroughly confused! :-0
Can you give a short example of the process one would go through if they
were logging in/registering from different parts of the application?
Steve
Hal Helms wrote:
>
> Cool. I think concrete examples are better. Here's a simplified version of
> RTG directories.
>
> /rtg
> /rtg/users
> /rtg/admin
> /rtg/catalog
> /rtg/cart
> /rtg
>
> All RTG circuits use one /rtg/users circuit for user interaction, just as
> you do.
>
> When we did kids, we put kids on the same level as rtg
>
> /kids
> /kids/internalCatalog
> /kids/supplierCatalog
> /kids/finder
>
> And then we could use /rtg/users for user interaction with Kids, too. Same
> thing with stuff like shopping cart and checkout.
>
> 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 11:09 AM
> To: Fusebox
> Subject: Re: reusing circuits (was Musings on Attributes)
>
> What I'm not seeing is how the directories are structured. I get the
> feeling from your examples that each circuit is totally independent of
> the others. So to make that work each directory would have to contain
> all the code for registering/logging in.
>
> Do me a favor. Give me a simple example of your directory structure for
> some of the circuits in roomstogo. This is what I'm envisioning your
> directories to look like:
>
> /products
> /products/users
> /customerservice
> /customerservice/users
> /users
>
> I'm picturing that "/users" directory is under each circuit that needs
> it and each one contains the same code for registering and logging in
> etc. Is that how you're doing it?
>
> Steve Nelson
> I hate to be the person to tell you this
> but.... you're not smart enough!
> http://www.secretagents.com/training
> (804) 825-6093
>
> Hal Helms wrote:
> >
> > 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
