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]
