On 12-04-08 04:42 PM, Ken McWilliams wrote:
> I don't know much about tiles internals but I want to learn... I
definitely
> want this functionality at run time as I would like that editor feature I
> mentioned to let definitions be altered at run time.
I would strongly advise against altering tiles definitions at runtime,
since it would involve thread safety issues. You can override attribute
values in a specific context, which is very different in nature. Not
sure if I'm making myself clear right now :)
MutableTilesContainer allows you to create new definitions at runtime
for the duration of the request. It might be useful in some specific
complex cases (mainly defining the structure of a web site based on many
request parameters), but usually an immutable container makes testing
easier.
> I've used tiles as a user for a couple years but for simple stuff...
hmm I
> can override the attributes at runtime but only before a the tiles
render,
> once it starts there is nothing I can do during rendering, right?
There are a few (unsupported) things you could do with the (internal)
context stack but definitely not what you explain below:
> Here is where my Tiles Ignorance is going to get high... I could test
this,
> but does tiles render each JSP separately and then include the content...
> or does it merge the tiles all into one big JSP and then render the
> content? I would much prefer the first... I've see the "preparer"
> attribute for definition tags, but what I need is during... so if
each tile
> where rendered independently in a determinable sequence (order of
> appearance by default) then assembled into a final template after the
fact,
> it would be easy to do what I wanted. The "body" tile in my case would
> render first, the tags in the body would just push CSS and JS resources
> (strings for paths) into a Set available to the request (well scoped the
> struts2 action). The "head" tile would render later and so everything
would
> work. Can something like this be done?
No, currently Tiles does no caching. It just takes the
HttpServletResponse and passes it to the various JSP in due turn for
writing directly into the response without further ado. The servlet
container may cache the data, but Tiles doesn't.
Although I must say I'm interested in introducing cache-related features
in a future version of tiles; it would enable out of order processing
and mixing some decoration with the composition mechanism as you've
noted, as well as some other interesting system-level optimizations. But
we're not there yet.
Nick.
