If you need to reuse code in Application.cfm in both your fa�ade CFCs and your page-based CF application, just abstract that logic into an application-scope CFC which you can call from both places (Application.cfm for page-based and psuedo-constructor for fa�ade CFCs). Same reuse, increased flexibility, modularity, and encapsulation, and no mixed paradigms.
Just to back Barney up on this, we do this with quite a bit of success:
/webroot
/Application.cfm
/system
/Application.cfcApplication.cfm has the cfapplication tags and tests to see if Application.cfc has been instantiated. If not, it does so and attaches it to the application scope, and then calls various app configuration methods. If a facade cfc is run, then it can pick and choose which methods should be instantiated specifically for the connection, and dump them into a different scope if needed. But the facade has access to the application scope.
We've run this using sessions and Flash Remoting just fine, but we haven't tested our system with the Flash standalone player. Our system uses a cfm page to embed a Flash widget, which uses Remoting to call data that is attached to the session object. One thing to note: the cfm establishes the session, but the Flash widget embedded in the page does not need to pass anything special to maintain the session; Flash makes the remoting call through the browser's http engine, and the session ID is passed as a cookie value from the browser.
--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: 310 478 6648
f: 310 235 2067----------------------------------------------------------
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]
