I am more of a DB person as well. However, the argument can be made against
writing things to a database before a transaction is complete (more trips
to the DB and all of that). Additionally, there is a limit to the number of
cookies a browser will hold from a given domain name (I can't remember what
that limit is off the top of my head though).
Using WDDX, you have to worry about string size limitation, but you can
store more variables in fewer cookies.
At 08:07 PM 6/4/2002 +0000, you wrote:
>Thanks for clearing that up.
>See, that's why I am more of a DB guy than a programmer.
>Personally I'd rather do it all with queries, then it's avliable in my
>DB for other apps, systems and what not to get at.
>However, I can see possible advantages of this sort of thing.
>
>Thanks again,
>Drew Harris
>
>Alan McCollough wrote:
> > The benefit of using structures (vs. arrays, or individual vars) exists
> > independently of what scope the var is in.
> >
> > Well, lets say you've got a user, and for each user you want an ID, a
> > username, and a fullname
> > You could go...
> > client.id
> > client.username
> > client.fullname
> > or you could do a structure "user"
> > and have
> > user.id
> > user.username
> > user.fullname
> >
> > So what?
> >
> > Want to see all the dope on your user?
> > <CFDUMP var="user">
> >
> > Want to have a load of 15 users?
> > <CFSET user = ArrayNew(1)>
> > <CFLOOP from="1" to ="15" index="loopindex">
> > <CFSET user[loopindex].id = {something}>
> > <CFSET user[loopindex].username = {something}>
> > <CFSET user[loopindex].fullname = {something}>
> > </CFLOOP>
> >
> > Then you can zip the whole wad up
> > <cfwddx action="CFML2WDDX" input="#user#" output="wddx_temp">
> > <cfset client.user = wddx_temp>
> >
> > And you want to git it back out?
> >
> > <CFSET user = ArrayNew(1)>
> > <cfwddx action="WDDX2CFML" input="#client.user" output="#user#">
> >
> > it's all good...
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> > > Sent: Tuesday, June 04, 2002 11:32 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: forcing user to login
> > >
> > > What is the advantage of putting complex data in a client variable
> > > anyway?
> > > Why would you not just have multiple client variables like:
> > > client.authenicated, client.userid, client.password, client.firstname,
> > > client.lastname...?
> > >
> > > -Drew Harris
> > >
> > >
> > > Jeff Peters wrote:
> > > > Well, you're not required to use WDDX, but the client scope will only
> > > > accept simple data types, so you must convert
> > > > the structure to a simple data type. Using WDDX is an easy way to do
> > > > that.
> > > >
> > > > - Jeff
> > > >
> > > > On 4 Jun 2002 at 14:30, Troy Murray wrote:
> > > >
> > > > >
> > > > > So let me make sure I have this straight. If I use CLIENT
> VARIABLES, I
> > >
> > > > > cannot use the structure
> > > > > that I'm currently keeping in a SESSION VARIABLE without performing
> > > some
> > > > > type of WDDX
> > > > > conversion back and forth?
> > > > >
> > > > > -T
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Richard Lamb [mailto:[EMAIL PROTECTED]]
> > > > > Sent: Monday, June 03, 2002 10:38 PM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: RE: forcing user to login
> > > > >
> > > > > My 2 cents. I think using client variables for the security
> aspect is
> > > > > great. But I also know that
> > > > > usually the bottleneck in an application are those darn database
> > > calls.
> > > > > Considering this, I think it
> > > > > would handicap you greatly to limit your thinking one way or the
> other
> > >
> > > > > exculsively. I think even in a
> > > > > clustered enviroments, you would benifit moving client variables
> that
> > > > > have extensive calls to
> > > > > session variables for the pupose of reading within the app.
> > > > >
> > > > > Rick
> > > > > -----Original Message-----
> > > > > From: Jeff Chastain [mailto:[EMAIL PROTECTED]]
> > > > > Sent: Monday, June 03, 2002 8:10 PM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: RE: forcing user to login
> > > > >
> > > > > For the original question ... I tend to build a fuseaction
> > > (checkLogin)
> > > > > that I can use
> > > > > cfmodule to call and check the users credentials. That way the
> > > actual
> > > > > check code is
> > > > > encapsulated in the login circuit (i.e. my current circuit only
> > > needs to
> > > > > know the user is
> > > > > logged in, not how to check for it). With the cfmodule call,
> I can
> > > also
> > > > > put it in individual
> > > > > fuseactions rather than trying to secure a whole circuit. So far
> > > it
> > > > > seems to work well and
> > > > > nobody has offered a reason yet not to do so (I can already here
> > > them
> > > > > coming ;-))
> > > > >
> > > > > On the second point, I as well have always stuck to client
> variables.
> > > > > The primary reason is just
> > > > > being lazy - I did not want to have to mess with locking session or
> > > app.
> > > > > variables. I have not had
> > > > > to deal with a clustered environment, but that would be a definite
> > > > > reason to avoid them. I have
> > > > > been debating trying session variables again now that MX does not
> > > > > require locking, but my client
> > > > > variables work fine - why would I need session variables?
> > > > >
> > > > > -- Jeff
> > > > > -----Original Message-----
> > > > > From: Timothy Heald [mailto:[EMAIL PROTECTED]]
> > > > > Sent: Monday, June 03, 2002 8:25 PM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: RE: forcing user to login
> > > > >
> > > > > I know the question wasn't directed at me, but as I only use
> > > client
> > > > > vars, I think I can add an
> > > > > answer.
> > > > >
> > > > > Ease of use.
> > > > >
> > > > > No locking. Ever. I don't feel the need to use application or server
> > > > > scoped variables either. What
> > > > > little I may loose by not using them, I make up for in
> performance. No
> > >
> > > > > variables maintained in
> > > > > memory, no fear of those variables getting corrupted. It's client
> > > > > variables, stored in a DB for me
> > > > > all the way.
> > > > >
> > > > > Tim.
> > > > > -----Original Message-----
> > > > > From: Troy Murray [mailto:[EMAIL PROTECTED]]
> > > > > Sent: Monday, June 03, 2002 8:39 PM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: RE: forcing user to login
> > > > >
> > > > > Drew,
> > > > >
> > > > > I'm curious, other then having clustered environments, was there
> > > > > anything else that lead you to
> > > > > use CLIENT vs. SESSION variables?
> > > > >
> > > > > -T
> > > > >
> > > > > -----Original Message-----
> > > > > From: Drew Harris [mailto:[EMAIL PROTECTED]]
> > > > > Sent: Friday, May 31, 2002 5:49 PM
> > > > > To: Fusebox List
> > > > > Subject: Re: forcing user to login
> > > > >
> > > > > I used session then at the last Fusebox conference got hammered
> about
> > > > > questions
> > > > > regarding it in the session I gave about using Fusebox for
> Enterprise
> > > > > applications
> > > > > when I was talking about this security app that I had built.
> > > > > Now I use a client variable, session variables are dangerous in
> > > > > clustered
> > > > > environments.
> > > > >
> > > > > And to answer your question, I put mine at the top of the fbx_switch
> > > > > page just before
> > > > > my cfswitch begins.
> > > > >
> > > > > -Drew Harris
> > > > >
> > > > > On 5/31/02 4:17 PM, "Tom Schreck" <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Where(tm)s the best place to put the logic to check for the
> > > presence of a
> > > > > session variable to
> > > > > determine if the user should be forced to login? The session
> > > variable
> > > > > indicated the user
> > > > > has logged in. The absence of one indicates the user needs to
> > > login.
> > > > > I(tm)ve tried the
> > > > > fbx_Setting in the root circuit, but it(tm)s not working.
> > > > >
> > > > >
> > > > >
> > > > > Thanks -
> > > > >
> > > > >
> > > > >
> > > > > Tom Schreck
> > > > >
> > > > > 817-252-4900
> > > > >
> > > > > [EMAIL PROTECTED]
> > > > >
> > > > >
> > > > >
> > > > > I have not failed. I've found 10,000 ways that won't work.
> > > > >
> > > > >
> > > > >
> > > > > - Thomas Edison
==^================================================================
This email was sent to: [email protected]
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9
Or send an email to: [EMAIL PROTECTED]
T O P I C A -- Register now to manage your mail!
http://www.topica.com/partner/tag02/register
==^================================================================
