Right now it instantiates for every request. If I looked at from an AMAZON.COM point of view, I would view this as very inefficient. I also hit the database one times for *each* composed object that I want to expand.
What I've discovered is that for my applications, there is no meaningful performance hit. If I notice one, I'll look at optimizing it. I can honestly say that I've given it some thought, but for now it is a solution in search of a problem, so I let it rest. My most complex application (from a data point of view) is a data collection app. I have some scientific patient data that is being collected. In one case, a form has 50 fields that are on an ability scale. So each of those data fields is normalized to include a look up to the ability scale (and the cfc is composed of 50 separate ability scale objects). So in order to expand this one object, I instantiate 51 objects and I hit the database 51 times (once for the original, and another for each of the ability scale lookups). This seems horribly inefficient. But in practice, the objects instantiate quickly and the instance data populates quickly, so I never bothered to make it more efficient. The nice thing is that I can easily override the default behavior for the exceptional case and optimize the performance. Meanwhile, 99% of my database access CRUD (and all of my getting and setting) is written for me as soon as I define the table in the database (since I use a cfc code generator that looks into the database and creates my <cfproperty> tags for me). ----------------------------------- Gerry Gurevich Application Development NIEHS ITSS Contractor Lockheed Martin Information Technology 919-361-5444 ext 311 -----Original Message----- From: Joe Rinehart [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 24, 2006 10:19 AM To: [email protected] Subject: Re: [CFCDev] CFML and Typing (was Bean and CFC question) Hey Gerry, Does this parsing happen each time you instantiate the given bean/object/etc. in question, or do you have some sort of cache for that information? It sounds like it could add some (but not many) runtime cycles. -Joe On 1/24/06, Gurevich, Gerry (NIH/NIEHS) [C] <[EMAIL PROTECTED]> wrote: > Jim, I'm not trying to talk you into anything. It looks like you've got > a system that works, but I do want to correct something that you said > for other readers. > > CFPROPERTY does not restrict your ability to create access restrictions. > If you go the cfproperty route, you have to write a cfproperty parser as > part of your super.init method. If you want you can create validation > methods and provide access control. I have been doing typing and > listing required fields in my version. I've been wanting to add more > features, but haven't had the time yet. > > That being said, I've been working with <cfproperty> in a stable way for > about a year now and have built some reasonably large and complex > applications with it. > > > > ----------------------------------- > Gerry Gurevich > Application Development > NIEHS ITSS Contractor > Lockheed Martin Information Technology > 919-361-5444 ext 311 > > -----Original Message----- > From: Jim Davis [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 24, 2006 9:54 AM > To: [email protected] > Subject: RE: [CFCDev] CFML and Typing (was Bean and CFC question) > > > I've not looked art the "mixins" idea yet (sounds neat tho') but you > might > want to take a look at the stuff I pointed to the other day. > > I found CFPROPERTY to have at least a few problems. It doesn't allow > for > access definition (you may want variables private or abstract but still > have > them defined in documentation). Using it as a meta data generator might > impair it's use as a web services descriptor (you might have private > properties that you want to define but that you don't want exposed to > the > web service. > > So I left CFPROPERTY to the web service domain and created a meta data > injector of my own. Each CFC can (optionally, of course) define all its > properties. These will be cached during the pseudo-constructor phase. > > The system already easily handles inheritance. It could easily be used > to > build aggregate supersets of multiple components. > > The only major change I'd like to make is applying the metadata directly > to > the existing metadata structure (if possible and performant) - right now > the > metadata cache is contained either in the application or the server > scope. > I don't like that as much. > > Jim Davis > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). > > An archive of the CFCDev list is available at www.mail-archive.com/[email protected] > > > -- Get Glued! The Model-Glue ColdFusion Framework http://www.model-glue.com ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.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' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
