Are you talking about the actual cf-level session scope here? (I'm not a mach-II guy, so sorry if I'm confusing that cf word with something specific to mach-II.)
If so, how does this strategy handle users who open multiple windows in the app? Multiple copies of the same object could be relevant to the session, each in a different window and each in a different state. Dave Merrill > In my case I created an object called SessionListener which knows > everything about the session. It has methods for setting stuff > in the session, and getting stuff from the session. In my > events, I simply use the 'getter' methods to retrieve copies of > my session objects and place them in the request scope, or use > the 'setter' methods to persist them in the session. This > prevents the rest of the app from needing to know anything about > the session. > > This approach also means I could rip the guts out of my > SessionListener and replace it with a bunch of calls to DAO's, > and the rest of the app would be none the wiser. The method of > persistence is not really important at that point .. now that I > think about it, 'PersistenceListener' might have been a better name =). > > Cheers > > Eric Knipp > Web Applications Supervisor > Unitrin Specialty - Insurance for U > www.unitrinspecialty.com ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
