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
