Re: Page composition strategy
On 6/29/10 6:23 PM, Chris Pratt wrote: I think the decision really comes down to which model you like better. No argument. I'm mainly using sitemesh with this project because I jump started it with appfuse, and that's what it used :-) -Dale - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Page composition strategy
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 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 section, and add into the 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 > >
Re: Page composition strategy
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 section, and add into the 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
Re: Page composition strategy
Hi Dale, 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. If You could provide such an example i'm sure most of us using tiles would know better when to switch to sitemesh. Actual situation for me is i know tiles and i stick to it. Best greetings, Paweł Wielgus. 2010/6/24 Dale Newfield : > On 6/24/10 5:33 PM, Brian Thompson wrote: >> >> Out of curiosity, has anyone on the list actually used both Tiles and >> Sitemesh? I'd really like to read a comparison of the two > > I used tiles with Struts1 about 6 years ago. > I've been using sitemesh with Struts2 for the last several years. > > I think that sitemesh is more configurable and less constraining. I recall > fighting tiles quite a bit. > > There's a chance this has changed, and if so someone please correct me, but > the basic architecture of the two are upside down from one another. > > With sitemesh your view layer executes (bottom up), then the output of that > is collected on the server and pushed through the decorator, which means you > can have the decoration change based on the content being decorated, but the > cost is that if you generate REALLY LARGE amounts of output for a single > page, that translates into REALLY LARGE temporary memory requirements in > your server. > > With tiles it constructs and outputs the page in order, so it can get handed > directly to the response and does not need to be stored on the server, but > in order to do that the output is generated in the order the tiles define > (top down), making it hard to do anything "special" in outer tiles based on > what's determined/displayed by the actual page content. > > -Dale > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Page composition strategy
On 6/24/10 5:33 PM, Brian Thompson wrote: Out of curiosity, has anyone on the list actually used both Tiles and Sitemesh? I'd really like to read a comparison of the two I used tiles with Struts1 about 6 years ago. I've been using sitemesh with Struts2 for the last several years. I think that sitemesh is more configurable and less constraining. I recall fighting tiles quite a bit. There's a chance this has changed, and if so someone please correct me, but the basic architecture of the two are upside down from one another. With sitemesh your view layer executes (bottom up), then the output of that is collected on the server and pushed through the decorator, which means you can have the decoration change based on the content being decorated, but the cost is that if you generate REALLY LARGE amounts of output for a single page, that translates into REALLY LARGE temporary memory requirements in your server. With tiles it constructs and outputs the page in order, so it can get handed directly to the response and does not need to be stored on the server, but in order to do that the output is generated in the order the tiles define (top down), making it hard to do anything "special" in outer tiles based on what's determined/displayed by the actual page content. -Dale - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Page composition strategy
Out of curiosity, has anyone on the list actually used both Tiles and Sitemesh? I'd really like to read a comparison of the two, not just "Sitemesh is quite easy to use." vs. "I don't think you can get much more simple than Tiles." All I really get from Googling is Sitemesh fanboys bashing Tiles as "inferior", but they don't really go into any detail. :( -Brian On Thu, Jun 24, 2010 at 4:11 PM, Ken wrote: > On Wed, 2010-06-23 at 10:36 +0100, Alex Rodriguez Lopez wrote: > >> I've been using Tiles and always found it confusing a little bit, now >> that I'm starting to test Sitemesh my vote would be for this last one. >> They accomplish the same thing, only Tiles is like saying each time "my >> page is made up of this, this and this". Sitemesh is more about taking a >> piece of a page and decorate it into a full page (more like >> "intercepting" or filtering). > > > I'd say that Tiles is like saying > only _once_ that my base page is > made of this and this... and each > subsequent page you should say > "extends" the base page, in my case > this means that > a different jsp is embedded into the > body which means a definition only > has one line. > > Each definition can of course > override any of the content in base, > for instance my base > has a left menu, header, body and > footer all defined, a tiles > definition typically overrides the > body > portion, but say I made a > "secureLayout" definition then every > page that a user needs to log in > to see will simply extend the > "secureLayout" definition. I have a > layout for displaying records... > "recordLayout" which redefines the > header and footer to provide > information such as where > the data was derived and how many > records and navigation between the > pages of the table. > > JSP's that then display records over > ride the body section of > "recordLayout" which simply > overrides > a different header and footer of the > Secure Layout. > > I don't think you can get much more > simple than Tiles. I'm not sure if > it is the right approach if > you had a really modular layout (say > you needed to let users add widgets > to any page). But if the layout is > really > hierarchical I'd say it's the way to > go. > > > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Page composition strategy
On Wed, 2010-06-23 at 10:36 +0100, Alex Rodriguez Lopez wrote: > I've been using Tiles and always found it confusing a little bit, now > that I'm starting to test Sitemesh my vote would be for this last one. > They accomplish the same thing, only Tiles is like saying each time "my > page is made up of this, this and this". Sitemesh is more about taking a > piece of a page and decorate it into a full page (more like > "intercepting" or filtering). I'd say that Tiles is like saying only _once_ that my base page is made of this and this... and each subsequent page you should say "extends" the base page, in my case this means that a different jsp is embedded into the body which means a definition only has one line. Each definition can of course override any of the content in base, for instance my base has a left menu, header, body and footer all defined, a tiles definition typically overrides the body portion, but say I made a "secureLayout" definition then every page that a user needs to log in to see will simply extend the "secureLayout" definition. I have a layout for displaying records... "recordLayout" which redefines the header and footer to provide information such as where the data was derived and how many records and navigation between the pages of the table. JSP's that then display records over ride the body section of "recordLayout" which simply overrides a different header and footer of the Secure Layout. I don't think you can get much more simple than Tiles. I'm not sure if it is the right approach if you had a really modular layout (say you needed to let users add widgets to any page). But if the layout is really hierarchical I'd say it's the way to go.
Re: Page composition strategy
BTW, any of those two are easily integrated into S2 as plugins (in fact already bundled with S2 distribution, just add the jars): http://struts.apache.org/2.1.8.1/docs/tiles-plugin.html http://struts.apache.org/2.1.8.1/docs/sitemesh-plugin.html I've been using Tiles and always found it confusing a little bit, now that I'm starting to test Sitemesh my vote would be for this last one. They accomplish the same thing, only Tiles is like saying each time "my page is made up of this, this and this". Sitemesh is more about taking a piece of a page and decorate it into a full page (more like "intercepting" or filtering). Allow me to throw in a vote for Sitemesh. I've never used Tiles, so I can't directly compare the two, but Sitemesh is quite easy to use and incredibly powerful for this sort of thing. You define it as a servlet filter in your project, and it adds decoration to the requests that come through. The JSPs never even have to know that they're being decorated in the first place! -Brian On Tue, Jun 22, 2010 at 1:35 PM, satyanarayana katta wrote: U should try tiles for this Sent from my iPhone On Jun 22, 2010, at 10:03 AM, "Antonio S." wrote: Hello. I'm a beginner in web development with Struts2 and I'm planning the structure of my application. Let me tell you my problem. With 'page composition strategy' I mean the strategy for making all pages in the application share the same HTML structure (header, left-column, content, right column, footer) using template inclusion mechanisms or others. Currently I'm using inclusion and all my JSPs share the same structure: A. 'include' prelude content: header, left-column. B. Specific content. C. 'include' coda content: right-column, footer. I don't like this approach and I'm thinking about alternatives; I wonder if Struts2 can help with this: i. Use the very same JSP template for all requests. That template would include specific content by calling the corresponding segment. This would involve a default result pointing to this JSP template and some means of specifying the name of the specific segment that will be invoked from inside the main template. ii. Use result pages as segments and render only specific content. Later on, some interceptor or servlet filter would include prelude and coda in the output stream. So, my questions are: 1. Can you recommend the best practice for page composition in Struts2? 2. Can I use Struts2 for implementing above mentioned strategies i. and ii.? How? Thanks for your time. Regards. Antonio. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Page composition strategy
I've been using Tiles and always found it confusing a little bit, now that I'm starting to test Sitemesh my vote would be for this last one. They accomplish the same thing, only Tiles is like saying each time "my page is made up of this, this and this". Sitemesh is more about taking a piece of a page and decorate it into a full page (more like "intercepting" or filtering). Allow me to throw in a vote for Sitemesh. I've never used Tiles, so I can't directly compare the two, but Sitemesh is quite easy to use and incredibly powerful for this sort of thing. You define it as a servlet filter in your project, and it adds decoration to the requests that come through. The JSPs never even have to know that they're being decorated in the first place! -Brian On Tue, Jun 22, 2010 at 1:35 PM, satyanarayana katta wrote: U should try tiles for this Sent from my iPhone On Jun 22, 2010, at 10:03 AM, "Antonio S." wrote: Hello. I'm a beginner in web development with Struts2 and I'm planning the structure of my application. Let me tell you my problem. With 'page composition strategy' I mean the strategy for making all pages in the application share the same HTML structure (header, left-column, content, right column, footer) using template inclusion mechanisms or others. Currently I'm using inclusion and all my JSPs share the same structure: A. 'include' prelude content: header, left-column. B. Specific content. C. 'include' coda content: right-column, footer. I don't like this approach and I'm thinking about alternatives; I wonder if Struts2 can help with this: i. Use the very same JSP template for all requests. That template would include specific content by calling the corresponding segment. This would involve a default result pointing to this JSP template and some means of specifying the name of the specific segment that will be invoked from inside the main template. ii. Use result pages as segments and render only specific content. Later on, some interceptor or servlet filter would include prelude and coda in the output stream. So, my questions are: 1. Can you recommend the best practice for page composition in Struts2? 2. Can I use Struts2 for implementing above mentioned strategies i. and ii.? How? Thanks for your time. Regards. Antonio. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Page composition strategy
Allow me to throw in a vote for Sitemesh. I've never used Tiles, so I can't directly compare the two, but Sitemesh is quite easy to use and incredibly powerful for this sort of thing. You define it as a servlet filter in your project, and it adds decoration to the requests that come through. The JSPs never even have to know that they're being decorated in the first place! -Brian On Tue, Jun 22, 2010 at 1:35 PM, satyanarayana katta wrote: > U should try tiles for this > > Sent from my iPhone > > On Jun 22, 2010, at 10:03 AM, "Antonio S." wrote: > >> Hello. >> >> I'm a beginner in web development with Struts2 and I'm planning the >> structure of my application. Let me tell you my problem. >> >> With 'page composition strategy' I mean the strategy for making all >> pages in the application share the same HTML structure (header, >> left-column, content, right column, footer) using template inclusion >> mechanisms or others. >> >> Currently I'm using inclusion and all my JSPs share the same structure: >> >> A. 'include' prelude content: header, left-column. >> B. Specific content. >> C. 'include' coda content: right-column, footer. >> >> I don't like this approach and I'm thinking about alternatives; I wonder >> if Struts2 can help with this: >> >> i. Use the very same JSP template for all requests. That template would >> include specific content by calling the corresponding segment. This >> would involve a default result pointing to this JSP template and some >> means of specifying the name of the specific segment that will be >> invoked from inside the main template. >> >> ii. Use result pages as segments and render only specific content. Later >> on, some interceptor or servlet filter would include prelude and coda in >> the output stream. >> >> So, my questions are: >> >> 1. Can you recommend the best practice for page composition in Struts2? >> 2. Can I use Struts2 for implementing above mentioned strategies i. and >> ii.? How? >> >> Thanks for your time. >> Regards. >> Antonio. >> >> >> >> - >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >> For additional commands, e-mail: user-h...@struts.apache.org >> > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Page composition strategy
U should try tiles for this Sent from my iPhone On Jun 22, 2010, at 10:03 AM, "Antonio S." wrote: > Hello. > > I'm a beginner in web development with Struts2 and I'm planning the > structure of my application. Let me tell you my problem. > > With 'page composition strategy' I mean the strategy for making all > pages in the application share the same HTML structure (header, > left-column, content, right column, footer) using template inclusion > mechanisms or others. > > Currently I'm using inclusion and all my JSPs share the same structure: > > A. 'include' prelude content: header, left-column. > B. Specific content. > C. 'include' coda content: right-column, footer. > > I don't like this approach and I'm thinking about alternatives; I wonder > if Struts2 can help with this: > > i. Use the very same JSP template for all requests. That template would > include specific content by calling the corresponding segment. This > would involve a default result pointing to this JSP template and some > means of specifying the name of the specific segment that will be > invoked from inside the main template. > > ii. Use result pages as segments and render only specific content. Later > on, some interceptor or servlet filter would include prelude and coda in > the output stream. > > So, my questions are: > > 1. Can you recommend the best practice for page composition in Struts2? > 2. Can I use Struts2 for implementing above mentioned strategies i. and > ii.? How? > > Thanks for your time. > Regards. > Antonio. > > > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Page composition strategy
On Tue, 2010-06-22 at 19:03 +0200, Antonio S. wrote: > So, my questions are: > > 1. Can you recommend the best practice for page composition in Struts2? Stand on the shoulders of others =) > 2. Can I use Struts2 for implementing above mentioned strategies i. and > ii.? How? Look into SiteMesh or Tiles. I use Tiles and find it to be very simple and very intuitive. My reason for using it over SiteMesh was that I was just learning Struts 2 and it looked simpler to set up for the first time. Of course this was based on about a minute of reading ;) so apply a lot of salt... but I have been very happy with Tiles. > Thanks for your time. > Regards. > Antonio.
Page composition strategy
Hello. I'm a beginner in web development with Struts2 and I'm planning the structure of my application. Let me tell you my problem. With 'page composition strategy' I mean the strategy for making all pages in the application share the same HTML structure (header, left-column, content, right column, footer) using template inclusion mechanisms or others. Currently I'm using inclusion and all my JSPs share the same structure: A. 'include' prelude content: header, left-column. B. Specific content. C. 'include' coda content: right-column, footer. I don't like this approach and I'm thinking about alternatives; I wonder if Struts2 can help with this: i. Use the very same JSP template for all requests. That template would include specific content by calling the corresponding segment. This would involve a default result pointing to this JSP template and some means of specifying the name of the specific segment that will be invoked from inside the main template. ii. Use result pages as segments and render only specific content. Later on, some interceptor or servlet filter would include prelude and coda in the output stream. So, my questions are: 1. Can you recommend the best practice for page composition in Struts2? 2. Can I use Struts2 for implementing above mentioned strategies i. and ii.? How? Thanks for your time. Regards. Antonio. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org