"In MX, using CFCs, you instead create a component that manipulates all of that as its own instance data - then you store an instance of that CFC in session scope."
Nice to hear it from you, Sean, because that's exactly the way I'm building one of my applications - and it works great. Gives you a nice repository and encapsulation of data for a session scoped object - such as a user profile. The fact of not having the request scope within the CFC instance isn't really a problem because controllers exist that do, and can pass that info to the CFC. Jeff -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean A Corfield Sent: Wednesday, March 26, 2003 10:45 PM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] Page context bug workaround On Wednesday, Mar 26, 2003, at 12:38 US/Pacific, Nathan Dintenfass wrote: > That said, I can't think of any other way to get at the request scope > in a > persisted CFC (though, as Sean might point out, it's probably best to > preserve encapsulation and pass any request variables into your CFC > rather > than rely make assumptions about the external environment -- but > that's a > different story). Yes, Sean would indeed point that out: good design limits the number of dependencies between a component and its environment. This is why a facade CFC can be so useful in managing other CFCs - the facade, instantiated on every request, can be the one place that 'knows about' session and request and so on. It, in turn, passes the relevant data into the other CFCs. This is quite a turnaround from how folks traditionally code session-based data in CF. Pre-MX, you would write a bunch of code that directly manipulated session scope data. In MX, using CFCs, you instead create a component that manipulates all of that as its own instance data - then you store an instance of that CFC in session scope. Old code: <cfparam name="attributes.username" type="string> <cfparam name="attributes.password" type="string> <!--- authenticate username/password ---> <cfset session.username = attributes.username> <cfset session.authlevel = variables.userAuth> ... New code: <cfcomponent> <cffunction name="loginUser"> <cfargument name="username" type="string"> <cfargument name="password" type="string"> <cfset var userAuth = 0> <!--- authenticate username/password ---> <cfset this.username = arguments.username> <cfset this.authlevel = userAuth> ... </cffunction> </cfcomponent> Use: <cfif not structKeyExists(session,"userInfo")> <cfset session.userInfo = createObject("component","user")> </cfif> ... <cfset session.userInfo.loginUser(uname,pword)> ... Hello #session.userInfo.username#! The user.cfc is no longer dependent on session scope so it can no longer clash with other code that uses session scope directly, and it can also be used to construct more complex user representations. (OK, this may not be a very compelling example but the principle is sound and can be applied elsewhere, for example a shopping cart CFC) Sean A Corfield -- http://www.corfield.org/blog/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
