The ColdSpring sample apps should be good examples of this approach. ColdSpring is really just a really souped-up Factory, so the examples could get you started on that type of architecture whether you intend to use the framework or not.
The controller layer simply asks the factory for objects... it's not responsible for creating them itself. Other than that the controller layer calls methods as usual on the objects it retrieves from a factory. -Dave >>> [EMAIL PROTECTED] 10/30/05 8:38 PM >>> So: 1. Regular CFCs are built to receive a GlobalFunctions CFC 2. All CFCs are created using a Factory object which handles the passing of the GlobalFunctions so you don't have to do it each time 3. A Config.cfc encapsulates the Factory.cfc so that the latter has access to config data such as DSNs, etc.? Does that mean that your controller never references any CFC besides Config.cfc? I would love to see a real, complex example of all this - know anywhere I could look? Cheers, Baz -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barney Boisvert Sent: Sunday, October 30, 2005 8:12 PM To: [email protected] Subject: Re: [CFCDev] Global Function Libraries The 'utils' CFC instance is a property of the CFC, accesible via getUtils(). The UDFs aren't copied into the variables scope directly. To take things the next step up, in an app you often have "peer" CFCs that need to know about each other, as well as standalone library-type CFCs that all the others need to know about. If all the CFC instances are created by a factory, then you can just pass that factory around and each CFC can get what it needs when it needs it, rather than passing around individual instance (like the utils object). I.e. factory.cfc has getUtils, getUserService, getNotificationService, etc. Each of those CFCs has an init() method that takes a reference to the factory that saves it to a variable, and then within it you can say variables.factory.getUtils().myUDF(), or variables.factory.getNotificationService().sendUserNotification(...). Bump that up one more level, and your factory object becomes a single element in your larger application configuration object. So your CFCs receive a 'config' object, with things like DSN, mail server, your object factory, and whatever else. So now you have a single "thing" that you can pass to all your application objects, and it has everything any of them need. cheers, barneyb On 10/30/05, Scratch <[EMAIL PROTECTED]> wrote: > > Hey Ryan, > > Why the additional getUtils() function rather than just referring to the > functions as variables.myUDF()? That method wouldn't be used outside the CFC > would it? > > Baz > > Suggestions so far: > > 1. Pass the function library to each CFC that needs it. > > -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. ---------------------------------------------------------- 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] ----------------------------------------- CONFIDENTIALITY NOTICE: This email and any attachments may contain confidential information that is protected by law and is for the sole use of the individuals or entities to which it is addressed. If you are not the intended recipient, please notify the sender by replying to this email and destroying all copies of the communication and attachments. Further use, disclosure, copying, distribution of, or reliance upon the contents of this email and attachments is strictly prohibited. To contact Albany Medical Center, or for a copy of our privacy practices, please visit us on the Internet at www.amc.edu. ---------------------------------------------------------- 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]
