It is perfectly possible to implement a HTML caching component - we have one for our site. I am working on getting permission to open-source it. It is a really simple bit of code and seems to work robustly without too many gotchas.
Ben Gidley www.gidley.co.uk b...@gidley.co.uk On Sun, May 3, 2009 at 11:10 PM, cfineman <cfine...@gmail.com> wrote: > > > > Thiago H. de Paula Figueiredo wrote: > > > > Have you done any profiling to know exactly how much time your > application > > is spending rendering? Most of the time bottlenecks are in other places > > (specially in the database). > > > > It's not really the rendering that I'm concerned about but rather the > ability to treat each of the components as a separate, independent "widget" > (possibly dynamically chosen) that could also be re-used by the outside > world... each one is it's own little MVC. The "pipeline" will also enforce > an SLA on each of the widgets. I want to do it server-side because there > are > SEO implications if it's done with AJAX. > > I'm not sold on the approach but I'm exploring options. Anyway, I'll just > have to ask you to give me the benefit of the doubt on this one; I've been > around the block a few times and I've got a good sense of the trade-offs > (including db optimization, caching etc). I'm not dismissive of the points > you and the other poster raised (far from it)... just saying they are > already in the mix of considerations. > > > > So now back to what I *want* to talk about ;-) > > I understand that it's a queue but the queue still implements an in-order > walk of the component tree (e.g. sibling A's setupRender....cleanupRender > happens entirely prior to sibling B's setupRender...cleanupRender). > > The more I think about it, the more it seems like the "Attached" or > "Activate" handler is the way to go since this is more of a "model > construction time" notion than a "render time" notion. > > -- > View this message in context: > http://www.nabble.com/Using-%22futures%22-to-parallelize-rendering-of-components-tp23353811p23360451.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
