out you lose whatever information is in the session.
By storing the information in the application scope and controlling timeouts
manually I can take action before deleting the in-memory data. In my case
this means storing the pages the user visited, resolution information and
some other stuff.
Jim Davis
_____
From: Kevin Marino [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 03, 2004 11:13 AM
To: CF-Talk
Subject: RE: CFC or Struct in session
Jim,
what do you mean by end-of-session processing?
thanks
-Kevin Marino
----------------------
Webmaster - HealthObjects
[EMAIL PROTECTED]
-----Original Message-----
From: Jim Davis [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 03, 2004 1:05 AM
To: CF-Talk
Subject: RE: CFC or Struct in session
Yup - I keep everything in the application scope. I turn off the session
scope.
I do have a unique struct (a collection of CFCs in fact) to store all the
users data and I have to manage timeouts manually.
The big gain here is end of session processing: I can track and store
clickstream information, resolution data, user selections, etc using a
custom end-of-session handler - you can't do that with the session scope.
It would be optimal if CF offered end of session processing directly, but
this is a workable solution. If done well (and I like to think I have) this
isn't even a performance drag - I've had 60,000 visits to a site (single
server) in a day using this architecture and have had no problems.
I disagree however that "copying" a CFC defeats its purpose: it's all in how
you architect things. I think there are two common misunderstandings about
CFCs:
1) CFCs are just structs: people use CFCs like they would structs and only
store data in them.
2) CFCs are just function containers: people use CFCs as persistence storage
for common functions and never store data.
There are times when each of these are useful but CFCs show their true power
(I think) when you combine the two ideas. An instance of a CFC has (or
rather can have) both data and functions to work with that data. You can
have a generic "User" component that also has a "getSessionDuration()"
method which calculates the session time (session creation to session last
access). You can have a function "isAdmin()" which can use to determine if
the user is an admin.
I can then say "<CFIF CurentUser.isAdmin()>".
This can all be done without CFCs of course but it seems much more elegant
to me to place all the user data (and functions that work with that data) in
a single container. Then create such a container for each one of my users
and store them in a collection. I've standardized the interface to my data
and the processes for working with it and encapsulated it all in a single
container.
In that case it seems perfectly normal to created a CFC instance for each
and every user - since that user CFC represents the IDEA of a user the
instantiated CFC instance represents some SPECIFIC user.
Just makes sense to me - but that doesn't mean it's "right", just that it
makes sense to me. ;^)
Jim Davis
_____
From: Taco Fleur [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 03, 2004 12:02 AM
To: CF-Talk
Subject: RE: CFC or Struct in session
"although technically I don't use the session scope but keep all user data
in the application scope"
Are you saying you keep data like, first name, last name, email (user info)
in the application scope?
You would have to have a unique struct name to reference them all by,
otherwise all user data would be overwritten each time, even so, the
application scope is not the ideal place to store that kind of data, the
application scope is more for application wide variables, like DSN, path
etc. The session/client scope is made to store user details...
I can;t think of any CFCs I would want to store in the Session scope either
(not yet anyway) - a CFC is an object you use in many places so therefore
the SERVER or APPLICATION scope would be the best there. If you use a CFC to
retrieve login details for example, why would you want to duplicate that CFC
many times across each session? that defeats the purpose of a CFC...
Taco Fleur
Blog <http://www.tacofleur.com/index/blog/>
http://www.tacofleur.com/index/blog/ <http://www.tacofleur.com/index/blog/>
Methodology http://www.tacofleur.com/index/methodology/
<http://www.tacofleur.com/index/methodology/>
Tell me and I will forget
Show me and I will remember
Teach me and I will learn
-----Original Message-----
From: Jim Davis [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 3 February 2004 2:44 PM
To: CF-Talk
Subject: RE: CFC or Struct in session
Since a CFC is a struct I doubt there's much different in performance. I
tend to place CFCs in the session (although technically I don't use the
session scope but keep all user data in the application scope) just because
it feels so good. Like walking barefoot through a tampon commercial-quality
meadow.
I can pass a "user" component around and pass it into other CFCs that accept
user components. You can do the same things with Structs tho.
CFCs do allow for stricter type checking however (something structs don't
have) and you get some nice initialization and compartmentalization aspects.
I can build a CFC that, just because it's that kind of CFC, knows that it
needs certain information and has defaults for it. It's not that you can't
do such a things with structs - CFCs just let you organize things better (I
think).
But as to whether it's more or less performant to use Structs or CFCs in the
Session scope I really doubt it matters. It might a little. but I'd be very
surprised to find out that there were any significant differences.
In the end I think it's more about personal preferences and architecture
than anything else.
Jim Davis
_____
From: Michael Dinowitz [mailto:[EMAIL PROTECTED]
Sent: Monday, February 02, 2004 10:15 PM
To: CF-Talk
Subject: CFC or Struct in session
I've been reading in a number of places where people place a reference to a
CFC in a users session variable. This has always seemed strange to me. Why
not cache the CFC for the application and only store the users data in a
session struct. Is there something I'm missing about saving an entire CFC
reference per user? Doesn't it have a higher overhead? Is there a
performance savings?
I'm going to bash on this tomorrow and find out myself, but if someone can
post their reasoning, I'd appreciate it.
Thanks
_____
_____
_____
_____
_____
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
