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
[EMAIL PROTECTED] wrote:
Hello all,
I would like to revisit the subject of integrating caching in
Tapestry.
Last time I talked about this, the conclusion was that it's to
difficult to implement caching because of the very dynamic nature
of the framework.
I'm about to develop an application that will need caching (this
app produce lots of binary content, charts, reports, it's
extremely database intensive and it will run in an already busy
server), and so I'm looking in the bowels of Tapestry to try to
implement cache, but I am way over my head and really need some
help with this.
What I need is to cache the response output using the value of
certain variables as a key.
Example:
Let's say I have a datagrid (with paging) that shows results from
a database. In this case the response output depends only in a
single variable, the page number. So the cache key is the page
number, and whenever there is a request for the datagrid if the
page number exists in cache all the processing is skipped and the
cached response will be presented to the user.
My first take at the problem was to subclass AbstractPage and
create a CachePage (similar to BasePage) and work from here,
but I'm having no success, it seems that I have to tackle this
somewhere above in the page life cycle, but I don't know where.
Suggestions to solve this problem are most appreciated.
Best regards,
Luis Neves
-------------------------------------------------------
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
Do you Yahoo!?
HotJobs - Search new jobs daily now
