The problem is context I guess. Usally your component depends on lots of stuff. Parameters, URL, Services, Page-state, component state, HTTP-Parameters and so on. Providing such a low-level cache might sound reasonable but remembering my own requirements lots of days back (2001) the cache depended on a flag system being triggered by distributed actions.
If you need your own cache (being driven that way) you might want to create your own component (check out the rendering pipe) <t:cached timeout="360"> <p>My Content to cache</p> </t:cached> Please report your findings. But I am in doupt such a general caching service is needed. But as far as I know Tapestry and its agility, all you need -----Ursprüngliche Nachricht----- Von: Tobias Marx [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 18. März 2008 17:58 An: Tapestry users Betreff: Re: @Cached and caching in general Ok. Thanks...this is what I wanted to know. What about an annotation for "components"/"pages ? @CachedOutput (time=3600) In this case a "component" or "page" would not render itself every time but cache its output to the filesystem (a cache directory). Every hour it would re-generate/refresh its output and this way save lots of performance..... -------- Original-Nachricht -------- > Datum: Tue, 18 Mar 2008 17:52:11 +0100 > Von: "Davor Hrg" <[EMAIL PROTECTED]> > An: "Tapestry users" <users@tapestry.apache.org> > Betreff: Re: @Cached and caching in general > @Cached is an annotation > that caches method call result per request. > so while page is rendering if multiple pieces of template require that > property it gets called only once... > > Davor Hrg > > On Tue, Mar 18, 2008 at 5:44 PM, Tobias Marx <[EMAIL PROTECTED]> wrote: > > I have not used T5 yet, but would @Cached use the file system for > caching HTML fragments similiar to caching mechanisms in some php frameworks? > > > > Or is this a pure memory-based cache? > > > > I am thinking about migrating an old PHP application to T5 - it has > really a lot of traffic and any users are logged in at the same time. > > > > It is quite a low-level application that is still quite fast due to > cron jobs in the background that generate HTML fragments that are > included to reduce the database-query bottleneck (e.g. > grouping/ordering and sorting of huge tables). > > > > Somehow I don't trust Hibernate for high-performance database > > queries > on huge tables .... as I think if tables are huge and many people > access it, it will always lead to problems...no matter how good the > queries are and how well you have splitted the data across several tables. > > > > So I think the best solution is always to generate HTML fragments > > in > the background that take a long time and simple "include" them....this > is even quicker then parsing templates when the data is cached. So you > save the time necessary for querying the database plus the time > necessary for processing the templates that are involved. > > > > Currently the setup on this application uses one-way database > replication and the cron jobs access the the huge data table on the > replicated database and generate those HTML fragments without > disturbing the web-applications performance. So the main application > simply includes those HTML fragments within milliseconds. > > > > But maybe the T5 caching mechanism would make all of those > > low-level > tricks redundant? > > > > > > -------------------------------------------------------------------- > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
