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 Merrill
----------------------------------------------------------
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]
