Thanks for the reply. I would love to use a framework (I have spent a few months re-writing some less mission-critical small apps in Model-Glue) but time constraints and team skills are lacking at this time ..... so next year for frameworks on this application.
I'm hoping that by the time we get to using a framework at least we will have the business logic and display pages decoupled enough to make the transition a lot easier. I take your point though about the widgets 'knowing too much' .... Trying to decide whether the page should be aware of where the widgets will go or the widgets themselves - and thinking the language of the text displayed in the widgets shouldn't be a concern of the business domain at all as its a display decision so should be a concern of the 'view' custom tags. On Sep 26, 1:49 pm, "Eric Knipp" <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
