What about client variables stored in a DB? In my application development, I
try to get the database to do as much work as possible. I also try to make
as few calls to the database as I can. I try to make every call count. With
client variables, aren't you hitting a database on every read and every
write of each little variable? What kind of performance issues are there
compared to session variables, which only use memory? I know Nat has an
opinion...
--
Jeffrey B. Marsh
Amateurs built the Ark.
Professionals built the Titanic.
-----Original Message-----
From: Michael Rahmn [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 30, 2000 9:02 AM
To: [EMAIL PROTECTED]
Subject: RE: Scope & Intranet Development
Can someone expand a bit on how and in what template client vars are
set and called. Say for managing a var IsLoggedIn. I'm having a hard
time understanding the resource issue. It seems wrong to query the
database on every page (app_globals) to make sure they are still
logged in. Thanks
PS This list has been a tremendous learning tool -- We've been able to
get our apps following the fusebox methodology except for the whole
state managment issue - still been using cookies for that.
| -----Original Message-----
| From: McCollough, Alan [mailto:[EMAIL PROTECTED]]
| Sent: Tuesday, August 29, 2000 1:30 PM
| To: '[EMAIL PROTECTED]'
| Subject: RE: Scope & Intranet Development
|
|
| >From a development point, I find db-based client vars
| infintely easier to
| work with. Since all the vars are on a SQL server, I can
| query the server to
| see the state of all variables at any point in an
| application's flow. If
| you've got a 2nd development workstation at your desk, with
| some sort of SQL
| query tool, or even a CF page to check status, you can spy
| out client
| variables while an application is functioning; not just
| when it bombs out or
| is CFABORTed.
|
| Also, the occasionally irritating issue of unwanted
| persistance is cured for
| good. Want to delete a client variable? Issue a DELETE
| statement, and you
| know its gone.
|
| Alan McCollough
| Web Programmer
| Allaire Certified ColdFusion Developer
| Alaska Native Medical Center
|
| > -----Original Message-----
| > From: Ryan Wood [SMTP:[EMAIL PROTECTED]]
| > Sent: Tuesday, August 29, 2000 12:26 PM
| > To: '[EMAIL PROTECTED]'
| > Subject: Scope & Intranet Development
| >
| > I am a CF intranet developer and very frequently use the
| session scope.
| > Most
| > of the state management is by a local employee ID. It
| appears that most
| > people and examples on this list use the client scope
| rather than the
| > session scope. Other than load balancing, is there an
| advantage to there
| > any
| > to the client scope over the session scope when not using
| CFID & tokens to
| > track state/user management?
| >
| > Are there any other intranet developers who are using fusebox for
| > corporate
| > reporting & applications? If so, please email off-list
| ([EMAIL PROTECTED]).
| > I'd
| > be very curious to hear about your implementations.
| >
| > Ryan
| >
| > __
| > Ryan Wood
| > Intranet Web Developer
| > Corporate Systems-MIS
| > Datastream Systems, Inc.
| > 864.422.5260
| > 800.955-6775 x5260
| >
| ------------------------------------------------------------
| --------------
| > ----
| > To Unsubscribe visit
| >
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebo
x or
> send a message to [EMAIL PROTECTED] with
'unsubscribe' in
> the body.
----------------------------------------------------------------------
--------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebo
x or send a message to [EMAIL PROTECTED] with
'unsubscribe' in the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.