>> Anything where the implementation may change, or have complex effects, get a >> getter/setter.
I haven't a problem modifying the existing get and set data methods to be bog-standard property getters and setters - each init() would wind up the properties with data and any property "set" would also pass the data back to the persist layer. nothing unusual there. it's the implementation of multiple versions of properties for each CFC - one for each company - that I've not settled on yet. each version would have exactly the same structure but differ only in data, based on the company_id. a typical site install would have between 1 and (say) 6 companies all using exactly the same codebase and db - that's why *company_id* is (currently) in every method call and query. Taken a step further, each company would use the same instance of each type of CFC, but would need to use company_id as it's "key" when refering to any properties of the CFC. it just strikes me that I won't have descrete properties per se, but one large struct with keys based on the company_id (which, I suppose, sums up a CFC's "variables" scope anyway - it just feels like a "wierd" idea, that's all...) At least a third of the total db data could be held as CFC properties in server scope if I can change it over. Presently, none of it is - they're all disparate method calls and no properties as such. It could reduce database hits by up to 50% (it's a very chatty system ATM) as an alternative, I've been thinking about multiple instances of each CFC (one for each company) but the idea of gettting a reference to the correct instance based on a users session.company_id doesn't "feel" right: eg: <cfset bOK = server.setup#session.company_id#.setparms(argumentCollection="#args#") /> so, any thoughts on the nested struct properties that each CFC would have? thanx barry.b -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm ---------------------------------------------------------- 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]
