Hmmm, i vaguely remember a time when i probably would have thought it was useful to use the THIS scope, back when i first encountered CFC's and they looked like fancy includes to me.
All ye champions of encapsulation, I salute thee! At least in one case, you've done well. :) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Nathan Dintenfass Sent: Tuesday, October 05, 2004 4:32 AM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] to use or not to use - instance data FWIW, I have to insert the obligatory urging to avoid using the THIS scope for instance data. The main reason is that you end up breaking encapsulation of your instance data, thus putting a great deal of trust into the hands of the CFC consumer. This can end up biting you later when you choose to change implementation assumptions, but code that uses your CFC may have operated on your public instance data using your old assumptions. Your end consumer of the CFC might also make bad assumptions about your THIS variables, causing unexpected (and hard to debug) behaviors in your CFCs. Joseph Flanigan wrote: > The term, "store data in the CFC", really means set variable values in > the namespaces defined by the CFC. > > When I built CFCSQLTool, I spent quite a bit of time testing and trying > alternative ways of handling data access layer (DAL) instance data > variables for table wrapper CRUD. The solution I chose was to instance > DAL data with the CFC using the this-scope variables. > > Here is the reasoning. > > At runtime, the CFC acts as a complex data structure where keys for > functions and instance variables have namespaces as variable names. > Instance variables are of type either this-scope or variables-scope. A > main difference between the two types is the means of setting values. > From the application perspective, this-scope values can be set as > object names whereas variables-scope require functions for setting and > getting values. (Programmers who practice encapsulation use the terms > getters and setters to refer to variable-scope functions.) Another > difference, is that with this-scope namespace memory allocation occurs > once whereas with function calls require several memory allocations. > But, because the DAL does so much work, reducing memory allocations > seems the better programming option. > > The build-time approach I like for coding is to split a table wrapper > cfc into 2 parts. One part for the CRUD functions and one part for the > instance variable structure which extends the wrapper. For an example, > see http://www.switch-box.org/CFSQLTool/doc_1_6_ReleaseNotes.html under > topic example service component. > > Joseph > > > At 07:01 PM 10/3/2004, you wrote: > >> firstly let me preface this post with two cavats: >> 1) I'm just looking for opinions, thoughts, etc to sway the decision >> one way or another. "Should we or shouldn't we" stuff >> 2) IMHO, the power (ands flexability) of CFC's comes from not just >> calling methods but in it's ability to store context data/values as >> well - "objects" >> >> For our enterprise app at the moment (a web version of a 15 yo legacy >> app), all data is returned based on what company_id a user has logged >> in at. this means that every db table, every method call - everything >> - needs this company_id to work (ie: each db table stores multiple >> company data where the companies are subsets of a particular >> organisation). >> >> (pls note: this is a legacy app - while I would not do things this way >> if I had a clean slate, it *does work*...) >> >> this means that for app-wide values (not specific entity data) either: >> >> - it may be pointless to store db data as object properties (depends >> on the user's context - session.company_id - from the login process) >> so the server-stored CFC's turn into no more than collections of UDF >> OR... >> >> - store cfc properties as arrays, based on company_id. sure this is >> more work, but at least we can persist "objects" in server scope and >> cut down on the db hits >> >> I know this is a wierd set-up but if anyone has any thoughts, >> opinions, advice, etc I'm all ears. >> >> 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] > > > ----------------------------------------------------------------------- > http://www.switch-box.org/CFSQLTool/Download/ > > Switch_box MediaFirm, Inc. > www.Switch-box.org Loveland, CO USA > > ---------------------------------------------------------- > 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]
