Just to follow-up: First, and I'll hijack this thread to address this shortly, I'm going to try the unicode route for the specific problem. But more generally, what I'm doing is passing in a utility object to any objects that need it, using setUtility() methods, so it's treated like any other property and I don't have to worry about the details of where it comes from, or what it's named. I like the idea of breaking utils up into smaller, specialized chunks, and I think I will do that next time. I would probably break them up into layer-specific chunks, such as a data layer utility object for my DAO/DG/TO objects, and a display utility object for my view managers. Right now, all of my objects are managed by an application manager object, so when I need to get at any other object, I can call application.appManager.getProductManager().getProductDAO() (I don't call other objects from within objects, only in fuses.) I am also storing the utility there, as appManager.getUtility(). If I understand correctly, storing the object in this appManager, and passing that reference into my objects when they are created is actually going to be more economical, since I'm not actually creating a new instance of the object.
Just to start yet another tangent :) can anyone point me to a good reference on using Singleton in CF? Again, thanks for all the input. - Ken On Apr 4, 2005 12:24 PM, David Ross <[EMAIL PROTECTED]> wrote: > I've been watching this thread with interest, because I think that the > dependency injection pattern is a solution to the problem that actually > fits CF's shortcomings. Since there's no "import" of libraries within a > CFC, one is either left to provide the library dependency during > instantiation, or require that your CFC goes and locates the library > itself. The first is obviously the better solution, however I've found > that it can get difficult to maintain as the number of dependencies > increase. > > Thus, when I have a "util" style CFC that is of interest to another > CFC, I usually have a setSomeUtil(org.utils.someUtil u) method to inject > that dependency. Sure, there are some thread safety risks at > instantiation time to be concerned about, but coded properly they can be > mitigated. > > The nice thing is that since my "container" is managing my > dependencies, adding a setSomeUtil(org.utils.someUtil u) method is all > that needs to be done to bring in a library (provided the container > knows org.utils.someUtil). I make don't make any changes to code that > "creates" cfcs. Also, when the time comes to swap org.utils.someUtil > with a different implementation, I don't have to change a single line of > code. > > -Dave Ross > > > On Apr 3, 2005 5:07 PM, Sean Corfield <[EMAIL PROTECTED]> wrote: > > On Apr 3, 2005 1:29 PM, Adrocknaphobia <[EMAIL PROTECTED]> > wrote: > > > Right now, during the init() of the main CFC I'm loading > oracle.cfc > > > and copying the methods to the base cfc and so forth for any other > > > imports I'd like to do. Problem is that this is not very elegant. > > > > What's wrong with just instantiating the utility CFCs as data > members and > > accessing the (public) methods directly? Heck, what's wrong with > just > > <cfinclude>ing the file containing the raw UDFs into your CFC > (outside any > > methods), thus making them non-public members of your own CFC? > > > > > extend these utlility cfcs in some sort of mind numbing chain of > > > complexity using... extends. Which, by the way, really sucks and > > > limits you from actually using extend properly. > > > > Correct. Inheritance is absolutely not the right approach for this. > -- > > Sean A Corfield -- http://corfield.org/ > > Team Fusebox -- http://fusebox.org/ > > Got Gmail? -- I have 50, yes 50, invites to give away! > > > > "If you're not annoying somebody, you're not really alive." > > -- Margaret Atwood > > ---------------------------------------------------------- > > > > 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] > > -- > Invite 50 Friends to Gmail! Who has friggin' 50 friends!? > > ---------------------------------------------------------- > 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] > > -- It's a metaphor for life itself. For that matter, everything in life is a metaphor for life. Except life. Life is probably a metaphor for metaphor. -- James Lileks ---------------------------------------------------------- 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]
