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 a legacy content service that probably won't get ported over immediately). Effectively I'd like to be able to send off some subset of the components to a "render farm" and then use tapestry to do the final assembly. The challenge (in my mind) is to be able to do this without having to explicitly link the components to their parent (I had thought about investigating hooking in to the class transformation code but that felt like the wrong way to go). It's not too hard to write this by hand (without using tapestry) but since we are starting to use tapestry for the rest of our front-end I was hoping we could stay within the T5 framework for this as well. Hope this clarifies what I'm after (or more the the point... I hope I didn't further muddy the waters! going to get coffee now :-) ) 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 components in it's own pools, and you can mark content that can be cached with @Retain annotation. I hope this gives some ideas, - Ville -- View this message in context: http://www.nabble.com/Using-%22futures%22-to-parallelize-rendering-of-components-tp23353811p23356900.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
