I'm not sure I fully understand your use-case.
You want to parallelize the rendering of the page?
You could potentially do that, but it would be tricky as tapestry goes
to great lengths to ensure that pages and components are "POJO", so
you don't have to worry about threading.
Parallelizing m
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, 2
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
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).
By the way, Tapestry does not have a rendering tree, but a rendering
queue. No recursion is used when rendering a p
Thanks for the response Ville,
Caching the component wont always work well since these are dynamically
rendered. Certainly we will consider caching when appropriate but, for
example, sometimes it's specialized by the user.
Also, much of this content is provided by non-Tapestry sources (we have
Just realized I need to clarify something... the future would be making an
HTTP request to retrieve the raw HTML (aka the "guts") of the component and
that would get inserted into the final DOM verbatim.
--
View this message in context:
http://www.nabble.com/Using-%22futures%22-to-parallelize-re
Hi,
Don't really understand the question, but if you're having perfomance
problems then caching would be the way to go?
You can use blocks to separate what ever you wish to wrap as T5 components
and place them to one central page, from which those blocks can be used.
T5 caches all pages and com
We have an app that's an aggregation of several 'components' (not yet written
in Tapestry... using an older in-house framework). Although each component
is not very expensive to create, the aggregate cost can get kinda high
sometimes.
I've been poking around Tapestry for the past couple of days t
