On Fri, May 29, 2009 at 3:53 AM, andreacfm wrote: > > Denstar, > > 1) Exists avanced caching system that can easily be adapted to MG > ( see ehCache for example ). > These systems are able to mange cache on ram as on disk as you > require. > Do you think igh traffic site use only ram caching?? > Is absolutely normal to craete more content caching in base of any > n number of variables you need.
I was just saying that it seems (to me, Read: not an expert) that if you store a lot of info in the session, you've got to replicate that info , right? Maybe I'm wrong, and there's no more overhead to replicating session data than say, application data-- from my limited exploration of caching, that doesn't seem to be the case, but I'm always 100% capable of being quite wrong. > 2) We are not talking of breaking MVC pattern. MVC pattern do not tell > you from which layer > an event can be invoked. What MG doeas is to adapt an MVC pattern > to an url call.....that's it. Yes, it's beautifully uncomplicated, isn't it? > I will try again and I will let it go.... I'm not meaning to frustrate you. There is a little communication barrier to deal with, nothing we can't handle. > I want to cache a view ok?? > This view needs data to produce an output ok??? With you so far... > I run my event first time. > Controller is fired and make logic for preparing data. > The views receives data make html and cache itself. Alright... > I recall the event. > The view is cached so do not need data but ..... controller is fired > in any case. > > Is that right??? > Is that efficient to you??? In an MVC pattern, I'd always expect the controller to be involved between my model and my view, so I'm not quite following you here. Are you suggesting that the view take over some (all?) of the controller's responsibilities? You want the view to handle cache control? If you "set it and forget it", why not go the dynamic to static content route, and leave the appserver out of the picture? The webserver itself can cache and serve out requests at some pretty impressive speeds... I guess what I'm not getting is how moving controller logic into a view makes caching easier/more robust. If I was going to get heavy into caching, I'd be doing the lion's share in my model, versus a non-agnostic location, such as MG. I love my MG stuff to be simple. I dislike how easy it is to start putting logic in controllers, or views, compared to in the model, where (IMHO) it belongs. So I think I'm a little biased, and probably come off as such. I always try to think (even tho I don't have to, really) "how would I use this same code in mach-ii or fusebox?", and similar thoughts. Heck, I like "helpers", but I know that when I rely on them, I'm relying on MG (which is fine, as I said, since I use MG, and don't really foresee moving frameworks-- but still. =]) Eh. I'm sorta wandering now, so I'll shut up. Sorry if I put you off with my demeanor. It just seemed that what you wanted was something I rail against in general. *blush* -- Dignity belongs to the conquered. Kenneth Burke --~--~---------~--~----~------------~-------~--~----~ 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 . -~----------~----~----~----~------~----~------~--~---
