Of course storing CFCs in the session scope won't work if you need session replication.
Matt Liotta President & CEO Montara Software, Inc. http://www.montarasoftware.com/ 888-408-0900 x901 > -----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).
