Jim, Have you heard of the pattern called "Template Method"?
Paul Kenney [EMAIL PROTECTED] 916-212-4359 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Nando > Sent: Sunday, May 09, 2004 3:29 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Best way to dynamically change method > bodies (from > "CFINCLUDE forces var scope into arguments?") > > > Jim, > > AFAIK, simply invoking or instantiating an instance doesn't > cost hardly anything - in > fact, it may only create a reference or a pointer - maybe > someone else could answer > that (i've been studying a little Java, thank you Mr. Helms). > I've sat and timed it > and it was always 0 ms. > > What the instance does after you create it is another matter, > of course. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Jim Davis > Sent: Monday, May 10, 2004 12:09 AM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Best way to dynamically change method > bodies (from > "CFINCLUDE forces var scope into arguments?") > > > Got it - this is pretty much exactly what I've built. I > wasn't building > separate components for each method, rather I'm building > single components > that encapsulate all the DB-specific methods. > > The only minor difference is that, right now, the DAO component (my > "Broker") doesn't persist with the component but rather is > being called > transiently using CFINVOKE. > > Any opinion on that? I go back and forth. I worry that > instantiating a > broker for every component could be a performance hit, but > CFINVOKE is a > little clunky and could be more a performance drain. > > I guess the question is that, in aggregate, is it more > expensive to call > something transiently or create many instances of it that > would only be used > rarely? > > I do like the idea of creating one prototype DAO/Broker that > would contain > all the needed methods. The DB-specific methods would then > extend that (and > could use it as a handy template). > > I'm implementing that now. > > Thanks for the time. > > Jim Davis > > > -----Original Message----- > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > > Of Matt Liotta > > Sent: Sunday, May 09, 2004 5:50 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [CFCDev] Best way to dynamically change method > bodies (from > > "CFINCLUDE forces var scope into arguments?") > > > > Whatever you want to call it, you don't need a session save > component > > for each type of database. For example, assume you have a session > > component with a save method that would call the appropriate DB > > component to save the session using the DB component's save > method. It > > might look like the following untested code. > > > > <cfcomponent output="false"> > > <cfset variables.config = ""> > > <cfset variables.dao = ""> > > > > <cffunction name="init" output="false" access="public"> > > <cfset variables.config = CreateObject("component", > "config")> > > <cfset variables.config.init()> > > <cfset variables.dao = CreateObject("component", > > variables.config.getDAOType())> > > <cfset variables.dao.init()> > > </cffunction> > > > > <cffunction name="save" output="false" access="public"> > > <cfargument name="session" type="struct" > required="true"> > > <cfset variables.dao.save(arguments.session)> > > </cffunction> > > </cfcomponent> > > > > In the above, the session component gets an instance of a config > > component allowing it to determine what DAO to use. Then it > creates an > > instance of that DAO for later use. When the save method is > called it > > just uses the DAO instance to save the session. The > assumption is that > > the config object reads some configuration information to determine > > what DAO is appropriate. Thus allowing you to change > databases simply > > by changing the configuration information. > > > > Matt Liotta > > R337 Consulting LLC > > http://r337.com > > > > > > On May 9, 2004, at 5:09 PM, Jim Davis wrote: > > > > >> First, create your base DB component and however many > child components > > >> you need for each specific DB. Then, create a session > save component > > >> that will take care of saving your session to your DB. > This is done by > > >> the session save component deciding which DB component to use and > > >> calling the appropriate methods. I would recommend that > the session > > >> save component read from a configuration file which DB > component to > > >> use. > > > > > > Isn't that (at least sort of) what I have with my > "broker" components > > > from > > > the first message? What am I missing? > > > > > > In that option I would have a Session_Broker.cfc for each database > > > type. > > > Creating the session object would also create a reference to the > > > application-defined broker component. > > > > > > Calling Session.save() would just be a fa�ade to call > > > "Session.broker.save(this)" (although whether the Broker > component is > > > persistent or not is still an open question). > > > > > > The implementation is then abstracted from the user (you > want to save > > > your > > > session you call "session.save()" ) but the DB-specific > code is still > > > available based on the properties of the application. > > > > > > The only issue here (which seems to be pretty common in > OO) is that > > > both the > > > Session component and the Session_Broker component need > to define the > > > same > > > method signatures (although one is only pointing to the other). > > > > > > The way around that would be to persist the broker and make a > > > reference to > > > it a property of the session object. Then you could call > something > > > like > > > "mySession.Broker.save(mySession)" - which really isn't too bad, I > > > guess. > > > Then there would be no persistence-related code in the Session > > > component at > > > all. > > > > > > I think what you're suggesting that the broker would not > be a property > > > of > > > the session object (the call would be something more like > > > "mySessionBroker.save(mySession)"), right? > > > > > > Something like this (using a broker) is how I'm currently leaning > > > since I > > > just don't like the downside of the Factory Method for this stuff. > > > > > > As an aside, I'm using "Session" just as an example: > there are several > > > components working together: DP_Application, DP_Session, > DP_Sessions (a > > > collection of the current DP_session components), DP_Request, etc. > > > > > > Most of them talk to either the database or filesystem > for at least > > > something (even if only for even logging). All of this works (and > > > works > > > pretty well, if I may say) but all of it currently uses > CFINCLUDEs to > > > set > > > DB/Filesystem-specific method bodies. > > > > > > That's what I'm trying to get away from. > > > > > > Thanks for the help, > > > > > > Jim Davis > > > > > > > > > > > > ---------------------------------------------------------- > > > 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]
