Just to make sure I understand your solution, let me restate it.

1. You have a CFM that loads any CFCs you want a single instance of into
hardcoded application scoped locations.
2. All uses of those CFC instances are done by referencing that hard coded
path.

The above certainly works, but I have two issues with it. First, I don't
like hardcoded locations. Second and more importantly, the solution only
works with singletons that persist for the entire life of the application.
It does not work for singletons that are only shared as part of a request.
Lastly, it seems this approach wouldn't be very convenient during
development as all the singletons would need to be reloaded on every request
since they may have changed as opposed to only reloading what is needed for
a particular request.

-Matt

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Kevin J. Miller
> Sent: Monday, September 06, 2004 2:03 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [CFCDev] singleton pattern
> 
> During the application initialization phase (essentially just a check for
> the var application.initialized), a series of structs is created within
> the
> application scope declaring factories.  All components that are sensitive
> to
> factories simply always look there.
> 
>       application.serviceFactory = structnew();
>               application.serviceFactory.bandwidthService =
> createobject("component","#application.paths.rootModelPath#bandwidthServic
> e"
> );
>               application.serviceFactory.bookmarkService =
> createobject("component","#application.paths.rootModelPath#bookmarkService
> ")
> ;
> 
>       application.presentationFactory = structnew();
>               application.presentationFactory.shell =
> createobject("component","#application.paths.rootPresenterPath#shellPresen
> te
> r");
>               application.presentationFactory.exception =
> createObject('component','#application.paths.rootPresenterPath#errorPresen
> te
> r');
> 
> Etc.
> 
> There is no ambiguity since the factories are only in the application
> scope.
> As far as a cfc's existence, app.cfm contains a check for
> isdefined("application.initialized") and if that fails it reads in the
> factory definitions (my snippet above) and keeps going.  There are also
> validation checks in certain instances when invoking some of these
> factories, but for all intents and purposes if you got to a page or cfc in
> the app, the app scope already contains the objects.  I'm reworking a
> medium
> sized app and have only tested on my dev server with myself, but so far
> the
> various components and the application.factory methodology has passed unit
> testing nicely.
> 
> -Kevin
> 
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Matt Liotta
> Sent: Monday, September 06, 2004 6:57 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [CFCDev] singleton pattern
> 
> 
> > This component that gets scoped to the application scope (it's a
> > service component).  It has some constructors, namely other cfc's it
> > uses internally (common functions, error related functions).
> >
> The problem I am discussing is more related to managing of CFCs in the
> application scope. You state that your component is in the application
> scope, but how does it get there? Where do you create it? How do "users"
> of
> said component know where in the application scope it is, whether it
> exists,
> etc?
> 
> -Matt
> 
> ----------------------------------------------------------
> 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]

Reply via email to