Thinking about a cfc-based app structure. Requests instantiate an area-specific controller object (companies, employees, users etc), and call the requested method (dsp_list, edit etc) of it. The area controller object instantiates objects within itself for that area's model and view components, as well as the global layout component (actually, its controller).
The layout controller object contains private instance vars for various common page elements (stylesheets, js_files, msg, page_body, page_ftr etc), and has getters and setters for each of them. Some of them may have default values (stylesheets, nav_bar, page_ftr etc). An area component typically calls those getters and setters to set the html displayed in them, add a local stylesheet or replace the global one, set a notification msg ("3 galaxies deleted"), etc. It then calls layout.dsp_global_layout(), or layout.dsp_download_layout(), etc to wrap itself with this global stuff as it's currently set up.
It sounds to me like the layout's controller is only the public interface to the layout object's instance vars and their getters and setters. The actual vars belong in the layout's model component, which would also need matching getters and setters, resulting in a nested component structure like this:
area controller area model area view layout controller layout model layout view
Make sense? Other ideas or comments?
Dave,
Not sure I understand, but this is where using a framework may be helpful. Mach-ii, with its associated sample applications, message boards, and so on has been valuable to me. I'm sure other folks can say the same for Fusebox or Tartan or whatever.
In Mach-ii, if I understand correctly, the framework acts as a front controller to the application, using listeners to interact with a model and passing data from listeners into views. I tend to create a listener for each major subcomponent of an application, or a complicated process or package, etc. Listeners call on Facades and Services, which call on DAOs and Gateways.
I also have several different websites that share a single model, so I created separate listeners calling the same DAOs. For example, the public room reservation website only interfaces with listeners that allow guests to reserve rooms, but the private website has listeners that track room maintenance.
Another benefit of using a public framework is that people can share a vocabulary. I try to encourage the use of design patterns in our code, but more importantly, if we do use a pattern, we use it exactly as defined, and try to avoid local fudging. Calling something a Facade when it's really a DAO makes it harder for future programmers to ask for help! :-)
Chris
--
*********************** Chris Dempsey Director, Information Services UCSB Graduate Division Quidquid latine dictum sit, altum videtur.
---------------------------------------------------------- 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]
