Sean, I agree with you. A question. In Coldbox you can pass keys to generate a unique cache copy. Why do not pass also an http_host variable to make a copy per domain?
What we are doing in MG is just fixing bugs that prevent MG to cache views. What we found is that the whole matter was completely skipped out. So there wasno way for MG to cache views at all. I will send code to Dan today and will post about that attaching a pacth so that more people can work on that. Sean. I am 100% with you on the fact that caching is a serious matter and must be tratated as it deserves. I have also tested in my life that a very high trafficated site has no way to live without a strong caching support an don this planet Coldbox is years above MG. Andrea On 5 Gen, 19:07, Sean Corfield <[email protected]> wrote: > On Mon, Jan 4, 2010 at 1:07 AM, Ezra Parker <[email protected]> wrote: > > I agree with Andrea that this is limiting, and that we should ideally > > include support for caching at a more granular level, but I don't > > think that allowing the caching of views directly is the best > > approach. I say this because unless one is dealing with a view that > > only references event data that is defined in the MG XML config (or > > does not pull anything from the event), then messages that are used to > > retrieve data for a view will still be broadcast even if the view > > itself is cached, thus partially defeating the purpose of caching. > > One thing I want to raise in this discussion before you go too far > down the rat hole of implementation is a really nasty problem I ran > into with ColdBox and its caching machinery... > > I'm working on a multi-domain application in ColdBox right now. By > that, I mean that we have a single instance of the ColdBox application > that responds towww.foo.comandwww.bar.com(and many other domains). > The domain name drives several features of the application, skinning, > user pool selection (for authentication) etc, etc. I've built sites > like this before with Fusebox and Model-Glue and it all works just > fine and dandy. > > When a framework adds caching, things can break really badly if the > authors don't consider multiple domains. > > In ColdBox, you can renderView('someview') and specify it should be > cached. Guess what? It doesn't respect the domain as a variable so > what gets cached on one domain is served up identically on another > domain - which can break things horribly! > > ColdBox does a lot of internal caching and we've had to work through a > number of similar problems (SES URL support was horribly broken in > early ColdBox 3 Beta releases due to this problem - now fixed in the > latest from SVN but still a weird mix of per-request and > per-application data). > > Please, as you're working on caching in Model-Glue, don't make these > same mistakes - make sure when you cache data, it works correctly > across multiple domains! > > FWIW, Luis has admitted that ColdBox was never designed to support > multiple domains (if only we'd known before we started the project!). > Model-Glue has worked flawlessly in multi-domain situations for me in > the past but I haven't tried it with the built-in caching... > -- > Sean A Corfield -- (904) 302-SEAN > Railo Technologies US --http://getrailo.com/ > An Architect's View --http://corfield.org/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood
-- Model-Glue Sites: Home Page: http://www.model-glue.com Documentation: http://docs.model-glue.com Bug Tracker: http://bugs.model-glue.com Blog: http://www.model-glue.com/blog 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
