Consider using Mach-II for this, even if you wind up with a business logic layer that is tightly coupled to the framework (you mentioned being short on time), you can use a single view for each different type of content and chain those views together as you see fit. Subroutines, introduced in 1.5will make this job even easier than before, and you can define your application declaratively through the mach-ii.xml configuration file, providing better visibility into the goings-on of the app (as opposed to making each widget know too much about itself).
Eric On 9/26/07, Alan <[EMAIL PROTECTED]> wrote: > > > We are about to implement a brand new design to our web application > and want to use the opportunity to refactor as much as possible during > the process. > > Turning the application into a fully blown OO application during the > project will not be possible due to time constraints (and skillset > constraints amongst the team!) > > The one thing we do want to drive in an OO way is the way page content > is retreived for a page. > > We have over 100 'skinned' versions of the site in several languages > and will be creating a flexible way to control what modules and > widgets appear on various pages. > > ie > The homepage for one 'partner' (skinned) site will have a 'job browse > using locations' widget , 'browse using job sectors' widget, 'job > search' widget and 'top news stories' widget. > The homepage for another partner will have a poll instead of top news > stories etc. > > The information for what goes on what page for what partner will all > be persisted and retreived from the database. > > I am currently exploring ways to handle storing this information in > memory to make pages display without trips to the database. > > The pseudo-oo approach is to simply have a query that has all the data > cached and a CFC to use a gateway method that does a QofQ on the > recordset to get whats needed for a particular page for the partner > site. > > Then on the display page it knows what css, js and custom tags to use > to display the page and various modules. > > Trying to think about this in an OO way is challenging but one pattern > that I have looked at, called Decorator, looks like a possible > solution. > > ie: a widget/page module object is decorated with another widget etc > etc until all widgets to be used are decorated with the page object. > Then the decorated object can be used to determine the display. > > The other option is simple composition. A page object composed of an > array of widget objects with each widget knowing its own position in > the page, language etc. > > So many ways to do it. > > Any ideas? > > By the way, at the moment we have a 'translations' array in > Application scope we use to display phrases in different languages and > lots of queries scattered everywhere that determines content and > hardcoded cfincludes on pages to widgets with lots of conditional code > like <cfif request.partnerid neq "86"><!--- dont show this widget for > this partner site ---> etc etc </cfif> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
