Yup, all that is possible with Tiles, especially with the new wildcard support in 2.1+. We had the head modification stuff working well in Tiles 2.0 and were able to have separate layouts for mobile vs desktop by using the new wildcard support. I'm in the early stages of learning sitemesh, so I can't speak as much to it's capabilities, but I haven't found anything I could do with one and not with the other (so far). I think the decision really comes down to which model you like better. (*Chris*)
On Tue, Jun 29, 2010 at 3:17 PM, Dale Newfield <d...@newfield.org> wrote: > On 6/26/10 4:26 AM, Paweł Wielgus wrote: > >> as a long time tiles user it would be very interesting for me to read >> about some specific problem that can be easily solved in sitemesh and >> hard or impossible to solve in tiles. >> > > One thing that's difficult to get right if you have to generate the page in > the order it is sent to the client is the header. > > Using sitemesh I can have my result specify snippets that the subsequent > decorator can add into the <head/> section, and add into the <body/> tag's > onload attribute. > > I am able to change the order of the html output to put side-bar output > below the main body content, no matter whether the result .jsp renders it > first or second. I can change the styling of the whole page (has side-bar > or not) based on logic determined once at display time rather than having to > do it twice (figuring out whether it'll appear while processing the action > and then figuring it out again during the display when figuring out what to > actually render there). > > One thing I have not tried to do with tiles that works well with sitemesh > is the ability to render the same content in different environments. > Specifically I have one set of decorations when a page is displayed in a > transient floating iframe and another when it's the normal page. I assume > that must be possible with tiles, but don't know how. > > > -Dale > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > >
