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

Reply via email to