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
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Sean Corfield
> Sent: Tuesday, November 23, 2004 7:34 AM
> To: [EMAIL PROTECTED]
> Subject: Re: AW: AW: [CFCDev] Validation
>
>
> On Mon, 22 Nov 2004 15:30:20 -0800, Ben Curtis
> <[EMAIL PROTECTED]> wrote:
> > Would one of your exceptions be the root cfc that cfcs
> inherit if we
> > don't specify an extends value?
>
> You mean like WEB-INF/cftags/component.cfc that all CFCs
> already inherit from? And it's empty.
>
> > machine.cfc is a
> > cfc.cfc
>
> No, a machine is not a CFC so that relationship doesn't match
> truck is-a machine.
>
> > Perhaps utilities, like some sort of extension to the
> language (e.g.,
> > ListWithNullsToArray, which will use ListToArray to convert
>
> No, that's what function libraries are for. Besides, many
> many CFCs do not use that function so it is not appropriate
> to make it compulsory for all CFCs.
>
> > I've typically seen such Utility code bundled up on it's
> own, and not
> > inherited.
>
> That's the right way to do it - as a library, not as a base class.
> --
> Sean A Corfield -- http://www.corfield.org/
> Team Fusebox -- http://www.fusebox.org/
> Breeze Me! -- http://www.corfield.org/breezeme
> Got Gmail? -- I have 1 invite
>
> "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'
> 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]
