Why not do an ajax call to an MG event that returns the HTML (or xml or json or whatever)? You can then use jQuery or innerHTML or whatever to replace your sidebar with the returned HTML.
Then in your controller you can handle your caching. Sean On May 28, 5:53 am, andreacfm <[email protected]> wrote: > Martin, > > Ok. > > I give the same example. > You have a sidebar of a web application. You have a site tree > navigation stored into a db ( like a cms should do ). > Any event is a page and in base of the event my sidebar will change. > > I have my controller.doSidebar ( I read db and push into event the > data I need to make my sidebar ) > I have my event-handler that broadcast and include the sidebar.cfm > view caching it. > > In normal way MG should fire the controller that read the db and make > his things, inject data into event and then at the moment of > creating the view will just include the cached html created at the > previous call.... > Controller fires for nothing and will do it for any event call. > A complex application can have many many views on a single pages that > should run a controller for nothing. > > Being my sidebar predictable in base of the event where we are ( as > most of the part of a web application based on a n number of known > variables that I could use to create more cached versions of my code ) > is a good candidate to be cached for long time, or for the entire > application life ( flush it when you need it ). > > If I could be able to run the controller from the view layer I should > have: > > Controller.doSidebar > My event-handler that broadcast the controller but do not include > nothing. Wait to be fired. > The 'main' event that include and cache my sidebar.cfm view. > > So first time view is inlcuded: > > runEvent('doSidebar'); > make html > > from this moment the runEvent will not be called anymore up to when > cache is flushed. > > I think cache is essential. > With a good caching layer performance increase of 2 3 4 times. > > I find a bit curioes that MG never implemented somethign like this > ( coldbox and Mach II have this functionality. > I also fine a bit curious to discover that MG caching content do not > completely work on MG3 beta. > > Andrea > > On May 27, 10:40 pm, denstar <[email protected]> wrote: > > > On Wed, May 27, 2009 at 6:05 AM, andreacfm wrote: > > > > Chris is easy, > > > > I want to cache a view and do not have the handler run again when the > > > view for which > > > hanlder prepare datas is cached. > > > That's really unefficient. > > > In the real world, sometimes we can't avoid doing "bad things" for > > "good performance" reasons, but what you're suggesting really seems > > like it should be doable within the MVC pattern. > > > Since you can "stack" views, how about caching the ones that don't > > change, and not caching the ones that do? > > > I'm thinking there's a way to do the thing you're asking about without > > mixing controller logic into your view, but I'm not completely sure > > without a use-case. > > > Can you give us a little real-world walk-through of what you are > > trying to accomplish? > > > -- > > The world is not comprehensible, but it is embraceable: through the > > embracing of one of its beings. > > Martin Buber > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "model-glue" 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/model-glue?hl=en For more about Model-Glue, check http://www.model-glue.com . -~----------~----~----~----~------~----~------~--~---
