Barney, Yes, handful of functions (15 in this common library), all in that single cfc. These functions are common to my app, but not so pervasive that I would have scoped the functions themselves into the application scope as part of a 'global function library' type thing (encapsulation issues with using them then in cfc's notwithstanding). FWIW, in the MVP framework approach (a la BatFink) that I use, the only place the common functions are used is at the Presenter level, never at the Model or View levels. I have other library type cfc's that I use in this same manner (error handling specific, wddx specific, et al) and their sizes lend themselves well to including them only as necessary without feeling (too much) like there is a needless bloat for functions that aren't being used. I've been happy with the results, but its hard to see the forest sometimes.
Thanks for the reply. Kevin > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Barney Boisvert > Sent: Tuesday, November 23, 2004 9:11 AM > To: [EMAIL PROTECTED] > Subject: Re: AW: AW: [CFCDev] Validation > > > I'd consider that a pretty reasonable approach. In a > language like Java that actually has static method calls, you > wouldn't use an instance like that, but with CF, that's the way to go. > > One question I do have is how have you elected to break down > the functions into different libraries? Or is you library > small enough that they're all in a single CFC? No criticism, > just curious; I've sat on that fence and never come up with a > compelling argument unless you have very few or very many functions. > > cheers, > barneyb > > > On Tue, 23 Nov 2004 08:55:16 +0200, Kevin J. Miller > <[EMAIL PROTECTED]> wrote: > > On this topic of global components that provide 'utility' > functions to > > other components, as in the Ben Curtis' example below with global > > functions that extend the language, I have implemented the > following > > scenario, would appreciate any thoughts. > > > > I have a common.cfc that contains these utility functions (normal > > stuff: cfscript compatible dump, writeFile() method, etc.). > The other > > componentry in the application (which are scoped to the application > > scope as factories) that require these functions instantiate an > > instance of the common.cfc in their constructors, to allow simple > > usage of the functionality: > > > > <cfcomponent displayname="Search Presenter" hint="Builds > and renders > > search views"> > > > > <!--- include common functions ---> > > <cfset common = createobject("component","common")> > > > > <cffunction name="someFunction" hint="Does something" > > access="public" output="no" returntype="struct"> > > > > <cfset someVar = common.someGlobalFunction()> > > > > </cffunction> > > > > </cfcomponent> > > > > The idea being that while it doesn't violate the usage of extends > > (is-a) it still provides almost identical 'native' usage of such > > libraries within cfc's. I don't know if this is common or > whether its > > done for example in Mach-ii, so I may be swatting at air > here, but I'd > > appreciate validation or criticism of the approach. > > > > TIA, > > Kevin > > > > -- > Barney Boisvert > [EMAIL PROTECTED] > 360.319.6145 > http://www.barneyb.com/blog/ > ---------------------------------------------------------- > 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 > [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 [EMAIL PROTECTED]
