> ...this king of component is useful for capturing output so it can be sent > via email for example.
This does not sound like a good idea. Do you mean requesting a page and cut it out or grabbing part of the DOM during same request. Just wondering... . -----Ursprüngliche Nachricht----- Von: Davor Hrg [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 19. März 2008 10:42 An: Tapestry users Betreff: Re: AW: @Cached and caching in general I agree that this is not something to take on lightly, and data should be cached, and rendering left as is. but besides caching this king of component is useful for capturing output so it can be sent via email for example. I like to keep most things stateless (only dependant on parameters), so from time to time I can use some of these nasty tricks. Davor Hrg On Wed, Mar 19, 2008 at 1:04 AM, Fernando Padilla <[EMAIL PROTECTED]> wrote: > :) > > True. I definitely won't say that this will solve all cases 100%. > But for basic rendering.. this allows you to essentially set > "expires" for fragments of the page. And yes it caches all > operations that go through PageRenderSupport. And if I could take > over the markupWriter properly, I would have cached and replayed > those already.. but i couldn't easily do that.. But on second > thought, you're right, maybe I should have cached a DOM tree.. since > it would have a much better guarantees for replaying. > > But on most cases, this component works pretty darn good, and we love it. > > Of course trying to do evict cache on particular events is hard.. but > if you are alright with "updates within 30hr" sort of cases. this is > a good start. > > > > > > Howard Lewis Ship wrote: > > I'm generally against these approached. > > > > Cache the data, make it fast to access. > > > > Let Tapestry do a full render every time. > > > > You'll end up with confusing, unforseen consequences. > > > > Rendering is increasingly a complex dance between components. > That's > the power and the penalty of Tapestry. Components inside > that cached > zone are not just rendering a character stream, they > are generating > JavaScript, assigning unique ids (via > PageRenderSupport) interacting > with an enclosing Form components, > and doing other user-specific > things. > > > > I would always look elsewhere first for places that need > optimization, > and I'd start with database access and queries. > > > > On Tue, Mar 18, 2008 at 11:22 AM, Fernando Padilla <[EMAIL PROTECTED]> > wrote: > >> We have a component that we call "Buffer" :) it takes a timeout, > >> optional cachekey, and optional lastmodified (to tell you) >> >> > We have it for Tap4 and Tap5, if anyone really wants it, I bet I can > >> liberate it.. you would just have to change the cache hooks to use > >> whatever cache you want to use... > >> > >> The easiest way to add caching to the app. :) >> >> >> >> > Martin Kersten wrote: > >> > @Chached is only used during a single page rendering cycle. It > would not >> > apply to your situation. (as far as I know) >> > > >> > Source: > >> > > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/ > >> > > >> > Your scenario would be implementable using your own component. > >> > The component would represent a fragment and read the file > (even >> > use a inmemory cache strategy (soft/weakreferences)) and > write >> > the ouput directly to stream (or actually the dom tree of > your >> > document being returned). > >> > > >> > Using your own solution enables you to mimic the behavior you talk > about. > >> > Another idea would to write / cache only datas needed to render > the tables >> > (e.g. cache only content not markup). Never the less > I am in doupt, >> > if such a solution is necessary (dynamically > cache results of >> > database queries in memory or on disk). > >> > > >> > So after all you might want to port your application. As always > use >> > the simpliest solution first. So database queries without any > caches. > >> > Once you see any problems (performance is below required) just > go for >> > optimization. Since you have a fallback solution at hand > (cron-jobs + >> > disk fragments) you are at the safe side. But I am > in doupt if you >> > really need the markup being cached. Caching > the database results >> > and recreate markup sounds more > reasonable. You might save you lots >> > of seeking time. > >> > > >> > But you always know: Only the code / application will tell you! > >> > > >> > > >> > Cheers, > >> > > >> > Martin (Kersten) > >> > > >> > -----Ursprüngliche Nachricht----- >> > Von: Tobias Marx > [mailto:[EMAIL PROTECTED] >> > Gesendet: Dienstag, 18. März 2008 17:45 > >> > An: Tapestry users >> > Betreff: @Cached and caching in > general >> > >> > 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] > > --------------------------------------------------------------------- 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]
