Another way of doing this is to use the EnvironmentProperty (in 1.8) which will let you set different properties and environment based stuff when the framework loads. Then use the use view-loader construct (in 1.8) -- you'll have to write your own if you use a db or use the PatternViewLoader if it's on disk - which is bundled to load views based on the environment properties that you setup. This will work provided that the application is deployed for each site / client. If the same application context excepts requests from multiple sites in the same application deployment, then you have to figure out everything during runtime (harder) than if you deploy the application per client. Customizations could be done by using XML includes functionality built-into Mach-II to override the base application (for that one client that needs something extra / different than the others).
I guess the real question is are you going to solve once by deciding when the application is loaded and therefore have one application deployed per client or if you are going to have to switch client context on each request. I would go with former -- it's going to be easier as it's less dynamic stuff going on per request (easier to debug). .Peter Zack Pitts said the following on 09/16/2009 09:31 AM: > Mercury, > > I wrote a high-profile CMS last year that uses a database to organize all > the views that need to be displayed at run-time. In my app, I have a > preProcess pageHandler plugin that determines which views to display based > on URL parameters at run-time and then performs a number of displayView() > methods from the eventContext. The results of those methods are stored in > the event object for display in my master template view. Works really well. > > > So instead of trying to hard-code things into the XML and figure out the > inner workings of Mach-II's view mechanisms, why not create related records > in a database to filter this information? > > Zack > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of MercuryNewt > Sent: Wednesday, September 16, 2009 7:18 AM > To: Mach-II for CFML > Subject: [Mach-II] Re: Delivering view programmatically > > > Thanks for the suggestion Brian. That might work, but I was looking > for a way of picking through the page-views that I had defined in the > mach-ii.xml file and for any given event, grab individual page-views > for a client based upon their specific configuration. Unless I'm > totally off in left field, I assume that the page-views or at least > the paths to those views are store in a struct or array similar to a > pool of available views and that some component within the Mach-II > framework grabs those views based upon what is defined in an event- > handler. I want to be able to do that without specifically defining > those page-views within an event-handler. I want to go get them 1 by > 1 if a client is configured to have a particular view. So, if views > A, B, C & D have been defined in the mach-ii.xml file and I have > clients 1, 2, 3 & 4, when a user logs into client 1's site I would got > get views A, B & C for the "homepage" event. But when a user logs > into client 2's site I would only get A & B for the "homepage" event. > Make sense? > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to Mach-II for CFML list. 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/mach-ii-for-coldfusion?hl=en SVN: http://greatbiztoolsllc.svn.cvsdude.com/mach-ii/ Wiki / Documentation / Tickets: http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/ -~----------~----~----~----~------~----~------~--~---
