Regardless of how it is accomplished, it would appear that there are
multiple ways to obtain an application context and a session context. But
of course, the fa�ade itself will not be persistent because it is
invoked/destroyed on each remoting request.
Yes, the fa�ade is new each time but it can refer to CFCs stored in session scope. The fa�ade itself should be very lightweight. Heavyweight 'service' CFCs should be instantiated at application startup and stored in application scope. Per-request and per-session CFCs should be instantiated as needed and, in the case of per-session CFCs, stored in session scope.
I guess one thing that still seems fuzzy is exactly how CF is maintaining
state with a Flash RIA. Normally CF is setting cookies - if cookies are
being set - exactly where are they being stored and does this info need to
be explicity added to the AMF header (i.e., CFID/CFTOKEN). What would happen
if the Flash Movie was running in a projector or in a non-CFM page?
It still works. The HTTP machinery in Flash can handle cookies. I do recommend using the J2EE Session Variables setting in CF Admin over the old-school CFID/CFTOKEN - J2EE session cookies are memory-based so sessions go away when the browser is closed and they are not stored on disk (so they are not as intrusive).
Sean A Corfield -- http://www.corfield.org/blog/
Got Mach II? -- http://www.mach-ii.com/
---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
