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
==^================================================================
