Ok, so that is basically the same as a fa�ade then, correct? Ben
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Dintenfass Sent: Tuesday, March 16, 2004 2:28 PM To: [EMAIL PROTECTED] Subject: [CFCDev] Session/Application inside a CFC, WAS: RFC, CFC Best Practices Ben: The short answer is that you wouldn't. In general, if you need to refer to such variables you would pass them in as arguments. A great example is the datasource for an application. It's quite common to store that as an application variable. So, you might do something like this in your Application.cfm: <cfset application.myCFC = createObject("component","myCFC").init(application.dsn)> You would then store the DSN as an instance variable in the variables scope (or in "instance"/"my"/etc. if you are doing the "virtual scope thing) and reference it as such. Same goes for session variables, where one common practice would be to simply put an instance of the CFC itself in the session scope but internally preserve encapsulation by using only instance variables. Make sense? > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Ben Densmore > Sent: Tuesday, March 16, 2004 11:01 AM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] RFC, CFC Best Practices > > > On Number nine it has: > > "Do not directly refer to external variables (i.e.: session/application > variables) inside a CFC. When in doubt, preserve encapsulation. The one > exception is when building facades for web services/flash remoting. This > means, for instance, passing in the dsn instead of referring to > application.dsn when doing database queries." > > How would you refer to a session or application variable going by this > guideline? > > Ben > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Barney Boisvert > Sent: Tuesday, March 16, 2004 12:31 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] RFC, CFC Best Practices > > I've found that using a struct in the variables scope for instance data > (I > use 'my') is helpful to separate actual instance data from computed > data. > Take a User business object for example. It'll have instance data such > as > 'name', 'username', 'password'. But it'll also very likely have a > validate() method which will check the values of those fields, and store > error flags somewhere for later recall by getValidationErrors() or the > like. > > Thus I'll have these fields: > > Variables.my.name > Variables.my.username > Variables.my.password > Variables.validationErrors > > Making the distinction allows to memento machinery to work better, and > also > allows generic get/set methods to be "safe". > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Dintenfass > > Sent: Monday, March 15, 2004 8:38 PM > > To: [EMAIL PROTECTED] > > Subject: [CFCDev] RFC, CFC Best Practices > > > > I've noticed that many of the best practices talked about on > > this list are > > not as widely known as I would have thought. What's worse, > > most of the > > basic best practices related to CFCs are not well documented or are > > documented in disparate places. > > > > I'm trying to capture a concise list of CFC best practices > > that everyone > > coding CFCs should be aware of (if not follow). > > > > Perhaps some of y'all have comments/additions/criticisms, > > which I'd welcome: > > > > http://www.dintenfass.com/cfcbestpractices/ > > > > ---------------------------------------------------------- > > 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] > > > > ---------------------------------------------------------- > 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] > ---------------------------------------------------------- > 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] ---------------------------------------------------------- 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] ---------------------------------------------------------- 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]
