Hi, Thanks for your input Mind Bridge. After thinking a bit on this issue I think I will follow Craig's suggestion, that way the cached data model is available to "non Tapestry" processes and as he says the design is better. I will keep your approach as reference for the future. Thanks for your input.
Best regards, Luis Neves On Monday 04 November 2002 20:10, Mind Bridge wrote: > Hi Luis, > Here is how I would do what you want (although normally this is not the > approach I would take): Create a component, say Cache, that can wrap other > content, e.g.: > <span jwcid="cache"> > ..... some content that you want to cache here, e.g. a table as you > mentioned earlier </span> > The Cache component would receive a key identifying the content via a > binding to determine whether the content is cached or not (e.g. the table's > state). If it is not, it would create a buffered MarkupWriter (probably by > extending HTMLMarkupWriter) and would invoke renderWrapped() with the > buffered MarkupWriter as an argument. Once the rendering is complete, it > can get the rendered content from the MarkupWriter and store it in the > cache. If cached, it would just get the content and pump it into the Markup > Writer passed to it without a need to render the wrapped template and > components. That's it -- simple to implement and extremely simple to use. > Nevertheless, do note that this method would NOT work with components that > communicate with other components outside the cached scope. For example, > components that talk to the Body (such as Script) would be automatically > "disqualified" from being cached. And since the whole idea of Tapestry is > to allow the use of components without caring how they are implemented and > whether they contain Scripts or not, this mechanism generally runs contrary > to the entire paradigm. Of course, you could wrap the entire page and be > sure that you will not have problems like that, but still, this would > bother me at least somewhat at a conceptual level. I think Craig is quite > right that caching the model in one form or another is probably the best > approach, since it does not have such issues and allows you much greater > flexibility in the long run, especially if one model is to be displayed > using several views (which something that it sounds like you might need). > It can also probably achieve up to 95% of the performance of the method > above. > > Best regards, > -mb > ------------------------------------------------------- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
