Thanks to Alan, Joseph and Bob for doing the all the arguing for me...and I
think I have my answer based on these discussions...but just so I am clear
(this is from the root)
[commandcenter]
[login]
both circuits are at the same level. If the user is forced into the login,
there is a place where they can click to create a new user profile.
However, profiles (new and edited) are located in the [commandcenter]
circuit. The conundrum is that one must happen before the other does. And
Bob has a good point that I don't want the "add a new profile"
actions/displayers files to be located in one place and the "edit an
existing profile" code in another when basically they both do the same
thing.
I think my solution will be either to place the profile information in the
login circuit like Hal does in his sample application or place a conditional
around the forced authentication check in the commandcenter circuit so that
if the point of entry originated at the login screen (the user chose to
click "add new user"), the authenticator is circumvented.
Whew. After all that the first option is the simplest. Oh well...my
drawing board had a smear on that spot anyway.
Thanks again,
Mike Craig
-----Original Message-----
From: McCollough, Alan [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 20, 2001 2:03 PM
To: Fusebox
Subject: RE: XFB Login Conundrum
Well it turns out I -do- have some duplicated code. Oh well! Hah! Never said
everything I did made sense, heh heh heh...
> -----Original Message-----
> From: McCollough, Alan [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, March 20, 2001 9:37 AM
> To: Fusebox
> Subject: RE: XFB Login Conundrum
>
> No, to the best of my knowledge, there isn't any duplicated code. If there
> was, I'd use the code in the public template, figuring its safer to let
> the
> restricted dip into the public, rather than letting the public dip into
> the
> restricted.
>
> > -----Original Message-----
> > From: Bob Silverberg [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, March 20, 2001 9:03 AM
> > To: Fusebox
> > Subject: RE: XFB Login Conundrum
> >
> > But is _any_ of the code duplicated between your public [sql] and
> [blocks]
> > directories and your restricted [sql] and [blocks] directories? If so,
> > you
> > are maintaining two versions of the same code, which is both a headache
> > and
> > an opportunity for problems (i.e., you make a change in one directory
> but
> > forget to make the change (or copy the file) in the other directory).
> >
> >
> > -----Original Message-----
> > From: McCollough, Alan [mailto:[EMAIL PROTECTED]]
> > Sent: March 20, 2001 12:21 PM
> > To: Fusebox
> > Subject: RE: XFB Login Conundrum
> >
> >
> > Hm. I faced this same hassle in the Mini-Help app I wrote, and nice
> folks
> > are now beta testing. The approach I took was to create two completely
> > separate fuseboxes, however, one is nested within the other. Like so...
> >
> > [root] app.globals, index.cfm, etc... this is public
> > [sql] sql templates. this is public
> > [blocks] code chunks. this is public
> > .......[admin] app.globals, index.cfm, etc. this is restricted
> > .......[sql] sql templates. this is restricted.
> > .......[blocks] code chunks. this is restricted.
> >
> > I found it worked out quite nicely. I had total isolation between the
> two
> > layers, and if I had to do this again, I'd do it this way again...
> >
> > > -----Original Message-----
> > > From: Bob Silverberg [SMTP:[EMAIL PROTECTED]]
> > > Sent: Tuesday, March 20, 2001 3:49 AM
> > > To: Fusebox
> > > Subject: RE: XFB Login Conundrum
> > >
> > > I place all of my fuseactions that can be executed by a non logged in
> > user
> > > in a single circuit app, called "public". I also have a "shared" file
> > > directory. This "shared" directory includes code that will prevent
> any
> > of
> > > the templates from being called directly from this directory. So I
> > place
> > > all of my fuseactions that anonymous users can execute (e.g., login,
> > > register) in "public", and I place any files that must be included in
> > both
> > > public and non-public pages in the "shared" directory.
> > >
> > > This works well for me,
> > > Bob
> > >
> > > -----Original Message-----
> > > From: Mike Craig [mailto:[EMAIL PROTECTED]]
> > > Sent: March 20, 2001 6:27 AM
> > > To: Fusebox
> > > Subject: XFB Login Conundrum
> > >
> > >
> > > I have been using Hal's latest on XFB and have an interesting
> conundrum.
> > > I
> > > have figured out one or two ways around this but none of them look
> very
> > > good. Here is the problem:
> > >
> > > From the root, I use two circuits, one for login and one for profiles.
> > > The
> > > profile circuit is actually a control center that requires the user be
> > > logged in, so the index.cfm file requires it.
> > >
> > > So, if you try to go to the control center, you first jump to the
> login
> > > circuit then come back to the control center. However, you can start
> to
> > > see
> > > the catch 22. If I ask to go to the control center and create a
> profile
> > > (where all that code should reside) I will first go to the login
> > > circuit...but I am trying to create a profile, not login.
> > >
> > > Of course my one solution is to share the profile code at a higher
> > circuit
> > > level and share it or another to copy the profile content files into
> the
> > > login circuit and the control center circuit.
> > >
> > > Is that enough to generate an idea or two?
> > >
> > > Mike Craig
> > >
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
