Yes, I use cf_returnfuseaction precisely for that purpose.
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 1:22 PM
To: Fusebox
Subject: Re: reusing circuits with XFB
Yeah, that's like how the <cf_returnfuseaction> tag works, except you'll
get some extra benefits of using this tag. Here is how you could do the
same thing with <cf_returnfuseaction>:
<cfif NOT loggedIn>
<cf_returnfuseaction
action="set"
gotourl="#self#?fuseaction=#XFA.login#"
returnurl="#self#?fuseaction=#xfa.return#">
</cfif>
By doing it this way your user could keep the focus on what they were
doing AFTER going through as many forms as necessary to obtain their
user record. Does that make any sense? Like this example Fuseaction
Flow:
View Product
|
Add to Cart
Start---- |
Login Form
|
Failed Login
|
Login Form
|
Failed Login
|
Register New User
|
Save New User
End---- |
Check Out Screen
The idea is that the user can go through as many pages as necessary to
login/register. It will maintain their focus on checking out so when
they finally finish with this side-process of logging in, they will be
sent to the checkout screen which is what they were trying to do from
the beginning.
This tag manages this process for you, so you don't have to pass a bunch
of Form/URL variables on where to send the user when they finish.
Steve
Hal Helms wrote:
>
> Yep, it's exactly like you would do it...only instead of directly calling
> the circuit like this:
>
> <cfif NOT loggedIn>
> <cflocation url="../Users/index.cfm?fuseaction="login">
> </cfif>
>
> I do this:
>
> <cfif NOT loggedIn>
> <cflocation url="#self#?fuseaction=#XFA.login#">
> </cfif>
>
> The value of self depends on whether the fusebox is in stand-alone mode or
> nested mode. Self always returns to the application root. So in this
case...
>
> /mySite
> /mySite/users
> /mySite/admin
> /mySite/admin/inventory
> etc...
>
> no matter where you are in the app, self always points back to /mySite and
> does so using whatever the value of XFA.login was set to in the fusebox.
> This gives me the chance for the users directory to inherit stuff from its
> parent, grandparent, etc. Also, if an exception occurs in
> /mysite/admin/inventory, I can decide whether to handle the error there or
> ignore it, in which case it will bubble up to admin and, if not handled
> there, to mySite.
>
> One nice thing about this is that you can test each circuit by itself
(since
> it can run unchanged as either stand-alone or nested). In test mode, you
> just point your browser to www.mydomain.com/mySite/users. When you want it
> as part of the bigger picture, you just point your browser to
> www.mydomain.com/mySite and users fuseactions will still work fine.
>
> The drag and drop would occur if I were to make mySite part of a bigger
> application, AllSites. Then I would just create another fusebox for
> AllSites, drag MySite into it, and register mySite in the Circuits.cfm
file
> and everything else would work without being changed.
>
> 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:59 AM
> To: Fusebox
> Subject: Re: reusing circuits with XFB
>
> 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
