>If you ever change the caching strategy you only need to update the call to
>the init() method of the products module rather than a bunch of references
OOPS!. Forgot to mention.. this a Responsibility Driven MVC Design - takes
after Jakarta Structs.
All Modules/CFC's are dynamically executed by a RequestManager.
The Controller initializes all the Data Caching as soon as the application
is initialized.
All CFC's have an init() method. In this case.
Products.cfc
init(){
variables.instance = structNew();
instance.prdData = application.appMainDataStore.getProductsCache();
}
The Controller executes all the init() method --> just like Java Constructor
and
initialized all instance variables.
All CFC's are dynamically executed with the Exception of "Specialized MVC
CFC's Or Caching"
Joe Eugene
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>Behalf Of Spike
>Sent: Wednesday, July 14, 2004 11:46 PM
>To: [EMAIL PROTECTED]
>Subject: RE: RE: [CFCDev] using cfinclude within components (was
>Serializationof CFCs)
>
>
>The standard way to do this would be to pass a reference to
>application.appDataStore into the products module. Either in the init
>function, or as required.
>
>So you might have something like this:
>
><cfset prodModule =
>createObject('component','productModule').init(application.appDataStore)>
>
>Then inside the products module you can do this:
>
><cfset instance.prdCache = arguments.datastore.getProductsDataCache()>
>
>That way your products module never needs to know where the
>datastore lives.
>
>If you ever change the caching strategy you only need to update the call to
>the init() method of the products module rather than a bunch of references
>inside the product module itself.
>
>Spike
>
>
>--------------------------------------------
>Stephen Milligan
>Code poet for hire
>http://www.spike.org.uk
>
>Do you cfeclipse? http://cfeclipse.tigris.org
>
>
>
>
>>-----Original Message-----
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED] On Behalf Of Joe Eugene
>>Sent: Wednesday, July 14, 2004 7:33 PM
>>To: [EMAIL PROTECTED]
>>Subject: RE: RE: [CFCDev] using cfinclude within components
>>(was Serializationof CFCs)
>>
>>
>>Sean,
>>
>>>reusable code. Referencing external stuff (like request scope or
>>>server scope) from inside an object is a violation of encapsulation.
>>
>>Agreed. What do you suggest? How would you do caching?
>>
>>Lets say you want to Cache some redundant data e.g. "States"
>>The states are stored as instance variables of a Class/Component.
>>
>>e.g.
>>"application.appDataStore" encapsulates all the Cached
>>Instance variables
>>and you have methods like getModuleData() returns cached
>>infomation from the
>>Class.
>>
>>In your Products Module you might do
>>
>>instance.prdCache = application.appDataStore.getProductsDataCache();
>>
>>Is there a better/cleaner way to do the above?
>>
>>Thanks,
>>Joe Eugene
>>
>>
>>>-----Original Message-----
>>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>>>Behalf Of Sean Corfield
>>>Sent: Monday, July 12, 2004 7:15 PM
>>>To: [EMAIL PROTECTED]
>>>Subject: Re: RE: [CFCDev] using cfinclude within components (was
>>>Serializationof CFCs)
>>>
>>>
>>>> Forgive me Sean but I can't see the problem.
>>>
>>>It's one of those things that really can't be explained if you don't
>>>'get' it... encapsulation is a good thing... it helps you build more
>>>reusable code. Referencing external stuff (like request scope or
>>>server scope) from inside an object is a violation of encapsulation.
>>>That's just a fact. Whether or not that violation of encapsulation is
>>>important to you depends on how much you value encapsulation. If you
>>>don't 'get' encapsulation then you won't value it so it's kinda
>>>moot...
>>>
>>>> <cfreturn request.kernel.utils.arrayostructs(qry) />
>>>
>>>That's a violation of encapsulation, plain and simple. Something
>>>Barney and I wouldn't do because we value the benefits of
>>>encapsulation but something that others would do if they don't yet
>>>view encapsulation as important.
>>>
>>>> but isn't instanciation of objects a performance hit?
>>>
>>>Depends. And even if it is, the performance hit may well be irrelevant
>>>compared to the benefits of maintaining encapsulation. It's that old
>>>saw about never optimize unless you know you have a problem and you've
>>>tracked it down to something specific...
>>>----------------------------------------------------------
>>>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]
