Clint,
You may want to check out Gabe's App Model. It was
discussed at the conference and I think there is some
info on it on Fusebox.org.
These days I find myself using a hybrid of the
app_model. I set all of the vars that I know will be
changing in request var structures on every page call.
Those that I know will be remaining the same stay in
either application or session respectively. However, I
keep the same app_model structure in my application
and session vars (i.e. application.site.datasource,
request.section.name, session.member.login).
Therefore, you can simply set all of your request vars
and not worry about the application and session vars.
I am still tinkering with the best way of laying this
all out, but I have found it to be a great way to
structure an app, pass variables around and not worry
about locking.
Nathan
--- Clint Tillerson <[EMAIL PROTECTED]> wrote:
> The refresh issues are the very reasons I so much
> want to use
> cflocation. But I typically have to to track so
> many variables
> throughout an entire session, I have not found a
> good way to
> manage this feat using cflocation.
>
> I have thought of the idea of forcing a form submit
> to carry the
> values, (rather than cflocation). This causes
> problems with users
> hitting the back button. If user tries to go back
> to the previous
> page, hitting the back button resubmits the form and
> doesn't allow
> them to go back to the previous screen.
>
> Related questions . . .
> Is there any reason why client variables are more
> commonly used
> in fusebox as opposed to session variables? And do
> you
> experienced "fuseboxers" out there typically track
> most variables
> as client/session variables EVEN if their values may
> frequently
> change throughout the user's session? My general
> rule of thumb
> has been if a variable is a "set value only once"
> type of variable
> (like user name, id, etc.) then store it as a
> session variable. If the
> value may change throughout the session, then track
> the variable
> via a form or url variable, else some unanticipated
> problem crops up
> where the user hit the back button to jump back
> three or four
> screens and the next action wasn't what was expected
> due to a
> session variable two screens ahead. Again, I
> reiterate, typically
> have to track a lot of variables, 50 - 60 is not
> uncommon at all.
>
> I'm trying hard to figure out how the fusebox
> methodology will fit our
> applications. I really like what I seen so far, but
> there are some
> issues. I have the book and think it's great. And
> I love the
> developer community on this list. I learn so much
> from you, even
> though I've not had the opportunity to build a "real
> fusebox" site.
>
> Thanks for your replies!!
>
>
> On 19 Jan 2001, at 6:31, Mike Craig wrote:
>
> > Fusebox commonly uses cflocation in its redirector
> files (url_ files)
> > and it is not required really. The whole point of
> these files is to
> > not only help move from one circuit to another,
> but also to help
> > prevent refresh message issues. You can pass your
> query string with
> > cflocation or if it is too large a set of
> parameters, you could break
> > the model a little and use the url_ file to create
> a form that traps
> > your current attributes you need on the next page
> and force a submit
> > to a new circuit to carry those values along.
>
>
> ------------------------------------
> Clint R. Tillerson
> Meteorologist/Programmer
> Pacific Environmental Services, Inc.
> 5001 South Miami Blvd.
> PO Box 12077
> RTP, NC 27709
> (919) 941-0333
> Fax: (919) 941-0234
> ------------------------------------
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
