On 7/8/02 8:31 PM, "Gabriel Sidler" <[EMAIL PROTECTED]> wrote:
> Jon, > I'd like to understand your thinking better. To me, caching > would be a very valuable add-on. But it's not clear it's something that should be in the control of the page designer. Why do you cache? Because the data that you are showing doesn't change often, or even if it does, there is some rule that says it's not critical to always show the most up to date info. > > Jon Scott Stevens wrote: > >> Why do you need to cache content like that? > > > Performance. The difference can be huge. > > What do you need to cache? > > - header > - footer > - navigation elements > - complex view snippets It can also be data as well. > >> Model >> View >> Controller >> >> Where in View do you see "Cache"? > > > I my understanding "caching" is a technique that is really orthogonal to the > MVC concept. It is applicable to any of the three tiers of MVC. I'm not sure - I can certainly see where you want to cache in the model, because that's where the 'logic' about the data is located. I think that one could make the argument that you also want to do that in the view, but it's a good question of how. For example, the designer can produce the bits, and there could be some kind of shared caching tool which manages caching templates. The designer stays in control of how it looks, but someone else worries about how often its rendered. You could do it, for example, with a modified #parse() directive, so as you assembled your page : <table> <tr><td>#parseCache($header)</td></tr> <tr><td>#parseCache($body)</td></tr> <tr><td>#parseCache($footer)</td></tr> </table> Or just do it with (ba da!) a tool : <table> <tr><td>$cache.render($header)</td></tr> <tr><td>$cache.render($body)</td></tr> <tr><td>$cache.render($footer)</td></tr> </table> And the logic of the refresh cycle is controlled by the $cache tool. > >> >> Why would you want to give the power of caching to your designers? > > > Because many aspects of the view are of no concern to the software > engineers that build the model and controller of the application. But caching is related to availability of data, and availability of system resource for delivery. I would assume that unless your designers are geniuses, or really understand the application and usage patterns, where the caching has to be done won't be clear from the outset. > Only the view designers should be concerned with page headers, footers, > navigation elements, view snippet A, view snippet B, etc. and therefore > only they are in the position to identify cachable view snippets. Mmmm. Not sure I agree. I agree that they are the only ones concerned with the headers, footers, nav, etc. But how they are cached? The example above, using the modified #parse() or the $cache tool, they can assemble the page (in what for me is a common pattern) and let someone else worry about how, when and what any rendered content will be cached. Once you add in user specific content, then this gets to be a much harder problem. > Of course, it would be wrong to cache parts of the model in the view. > That would be really bad practice. > > Now, I am sure that none of my arguments are new to you. I'd like > know how you propose to cache view snippets or why it is a bad idea > in general. > > > Additionally, one thing that is not addressed by Rick's idea > and that would be a cool feature is the caching of entire pages. > The usefulness of such a page caching scheme would depend very much > on the control the view designer has over specifiying the life time of > cached pages. For example, the life time of a cached page could be > tied to > - time (the obvious) > - the life time of a session > - the value of an application-scope variable > - the value of a velocity context variable > - the value of a HTTP request parameter > etc. > > Where would such page caching support go? I am not quite sure. > One approach would be to implement it as a layer on top > of Velocity, for example inside VelocityViewServlet. Not sure it even belongs in VVS. (or VS) I think that it could be done as a separate utility that VVS or a class derived from VS could be used.. There are generic caches out there (Jcache/JCS?) - no need to reinvent. An integration interface is all that I think is needed... > > > Gabe > > >> >> Bah. #cache isn't in there because it is a bad idea. >> >> -jon >> >> >> -- >> To unsubscribe, e-mail: >> <mailto:[EMAIL PROTECTED]> >> For additional commands, e-mail: >> <mailto:[EMAIL PROTECTED]> >> >> . >> >> > -- Geir Magnusson Jr. Research & Development, Adeptra Inc. [EMAIL PROTECTED] +1-203-247-1713 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
