Struts / Tiles Design question
I'm recoding an existing app using Struts and Tiles. The app originally used frames with the usual components of header, menu, body and footer. I've replaced the frameset with a layout template and it works fine. The difficulty I'm having is when I only want to refresh the menu tile and not repeat all the work to create the body. e.g. the user clicks on an image in the menu that opens up a tree node to show sub-menus - only the menu model and view are changed. With frames this was easy, but with Tiles it's not so easy, at least not for me. There are two problems: - Is there a way to process just the menu HTML and avoid re-generating the body, header and footer?. - If all tiles must be regenerated, how should I define the Action for the menu change. This should really just call a menu handler page but if the entire page must be regenerated, then I need to specify the action for the current Tiles definition and retain state. I've considered trappping and caching the generated HTML from each response and replacing only the changed menu but that doesn't seem clean. Anyone have any guidance?
Re: Struts / Tiles Design question
For your second question I believe the answer is to create a new tiles definition where you override the menu tile. In your action reference the new definition. But your first question I don't know. I am now building my first large corporate struts app and am using tiles which I like very much but am very worried about speed and wonder whether I should use frames to speed things up( for your re-gen reasons as well as the caching of images, javascript ref tables, etc on a fixed frame such as navbar). So I am curious how tiles would run on top of frames and whether I should consider it. - Original Message - From: Carl Hope [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Sunday, January 19, 2003 9:07 AM Subject: Struts / Tiles Design question I'm recoding an existing app using Struts and Tiles. The app originally used frames with the usual components of header, menu, body and footer. I've replaced the frameset with a layout template and it works fine. The difficulty I'm having is when I only want to refresh the menu tile and not repeat all the work to create the body. e.g. the user clicks on an image in the menu that opens up a tree node to show sub-menus - only the menu model and view are changed. With frames this was easy, but with Tiles it's not so easy, at least not for me. There are two problems: - Is there a way to process just the menu HTML and avoid re-generating the body, header and footer?. - If all tiles must be regenerated, how should I define the Action for the menu change. This should really just call a menu handler page but if the entire page must be regenerated, then I need to specify the action for the current Tiles definition and retain state. I've considered trappping and caching the generated HTML from each response and replacing only the changed menu but that doesn't seem clean. Anyone have any guidance? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts / Tiles Design question
I believe there is no way you can refresh part of a layout; the whole layout jsp will have to reload. For your second question, you can write the menu part of your layout (say 'menu.jsp') in a way capable of recognizing the current section selection of the user and self-expand accordingly... On Sunday, January 19, 2003, at 09:07 AM, Carl Hope wrote: I'm recoding an existing app using Struts and Tiles. The app originally used frames with the usual components of header, menu, body and footer. I've replaced the frameset with a layout template and it works fine. The difficulty I'm having is when I only want to refresh the menu tile and not repeat all the work to create the body. e.g. the user clicks on an image in the menu that opens up a tree node to show sub-menus - only the menu model and view are changed. With frames this was easy, but with Tiles it's not so easy, at least not for me. There are two problems: - Is there a way to process just the menu HTML and avoid re-generating the body, header and footer?. - If all tiles must be regenerated, how should I define the Action for the menu change. This should really just call a menu handler page but if the entire page must be regenerated, then I need to specify the action for the current Tiles definition and retain state. I've considered trappping and caching the generated HTML from each response and replacing only the changed menu but that doesn't seem clean. Anyone have any guidance? Cagan Senturk Emirca Technologies, Inc. 75 Spring St. Floor #8 NYC, NY 10012 mailto:[EMAIL PROTECTED] http://www.emirca.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts / Tiles Design question
Carl Hope wrote: - Is there a way to process just the menu HTML and avoid re-generating the body, header and footer?. - If all tiles must be regenerated, how should I define the Action for the menu change. This should really just call a menu handler page but if the entire page must be regenerated, then I need to specify the action for the current Tiles definition and retain state. I've considered trappping and caching the generated HTML from each response and replacing only the changed menu but that doesn't seem clean. Anyone have any guidance? Could you use something like OS Cache tags to cache the individual tiles that don't change. I've been using it and it is working well for me. Very simple. See http://www.opensymphony.com:8668/space/OSCache Regards, Paul - Paul Hodgetts -- President, Principal Consultant Agile Logic -- www.agilelogic.com Consulting, Coaching, Training -- On-Site Out-Sourced Development Java, J2EE, C++, OOA/D -- Agile Methods/XP/Scrum, Use Cases, UI/IA -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts + Tiles: Design Question
Hello, You can have the html:form.../html:form tag in a common tiles ancestor inserting sub-tiles. Each sub-tiles can have tags like html:radio or submit. There is an example of that in tiles documentation (tiles-doc/tutorial/invoice/*.jsp). In this example, editInvoice.jsp declare the form, and then insert editAddress.jsp which use html:text. Hope this help, Cedric Sri Sankaran wrote: I am unable to use a common ancestor because some tags (such as html:select, html:radio) must be nested in a form and it doesn't recognize that this is indeed the case: Layout-Begin html:form .. Body-Tile-Begin html:radio Body-Tile-End .. Nav-Tile-Begin Previous-button Next-button .. Nav-Tile-End /html:form Layout-End So, I am forced to have the form tag in the Body-Tile. Even then I am forced to use JavaScript to indicate which of the buttons in the Nav-Tile was pressed. Could you elaborate on how you workaround it? Sri -Original Message- From: Trieu, Danny [mailto:[EMAIL PROTECTED]] Sent: Friday, May 24, 2002 11:33 AM To: 'Struts Users Mailing List' Subject: RE: Struts + Tiles: Design Question Cedric, You are right on the point. I been using this strategies over and over again to share from amon difference action. I works well for me, plus I really hate having JavaScript or hidden field to indicate which action your are intended to submit. I think this is the right way to do cuz you really do separate the controller logic from presentation logic, or you can say .. hidding the controller logic by abstracting the presentation. danny -Original Message- From: Cedric Dumoulin [SMTP:[EMAIL PROTECTED]] Sent: Friday, May 24, 2002 3:19 AM To: Struts Users Mailing List Subject: Re: Struts + Tiles: Design Question There is several strategies. Are you sure that you need one single form for navigation and body ? * If navigation and body aren't related, you can put several forms, only one will be selected by browser when submitting. * If navigation and body are related, you need a common ancestor in the Tiles philosophy. A common ancestor is a tiles that will insert related sub-tiles. This ancestor contains the form, and sub-tiles contains form's elements. In your case, you can have an ancestor body playing this role, and inserting the navigation and real body Hope this help, Cedric Sri Sankaran wrote: Struts version: 1.0.2 Servlet engine: Tomcat 4.0.2 I am trying to build a wizard framework using Tiles. It follows the standard Windows wizard metaphor with a body panel and navigation buttons below. I am running into a problem and would like any opinions/suggestions. A logical use of Tiles would call for the body and nav buttons to be separate tiles that are combined using the tileDefinitions file. For example: definition name=Wizard path=/wizardLayout.jsp put name=titlevalue=Title.jsp/ put name=body value=/ put name=navigation value=Nav.jsp/ /definition !-- Intro page -- definition name=Intro extends=Wizard put name=bodyvalue=workflow/intro/intro.jsp/ /definition Here, the wizardLayout.jsp is solely responsible, as the name suggests, for laying out the various tiles using necessary HTML tags. The problem with this strategy is that by separating the body and nav into separate tiles limits the use of the Struts html:form tag. Firstly, the begin and end form tag must be in the same JSP. This prevents the tag from beginning in the 'body' tile and ending in the 'navigation' tile. There are other complications, even if I'm willing to compromise the design and place the html:form tag in the layout page (wizardLayout.jsp above). This would require some convoluted JavaScript that sets the form's action attribute on each page. The only workaround I have found is to have the body the navigation in the same tile; in other words -- not have a 'navigation' tile at all. This has a serious shortcoming in that it forces every body panel (i.e. every page in the wizard) to have knowledge of layout and therefore responsible for its maintenance. I really like the concept of Tiles and would love to use it to its fullest. Do you have any suggestions? Am I missing something fundamental? Sri -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED
Re: Struts + Tiles: Design Question
There is several strategies. Are you sure that you need one single form for navigation and body ? * If navigation and body aren't related, you can put several forms, only one will be selected by browser when submitting. * If navigation and body are related, you need a common ancestor in the Tiles philosophy. A common ancestor is a tiles that will insert related sub-tiles. This ancestor contains the form, and sub-tiles contains form's elements. In your case, you can have an ancestor body playing this role, and inserting the navigation and real body Hope this help, Cedric Sri Sankaran wrote: Struts version: 1.0.2 Servlet engine: Tomcat 4.0.2 I am trying to build a wizard framework using Tiles. It follows the standard Windows wizard metaphor with a body panel and navigation buttons below. I am running into a problem and would like any opinions/suggestions. A logical use of Tiles would call for the body and nav buttons to be separate tiles that are combined using the tileDefinitions file. For example: definition name=Wizard path=/wizardLayout.jsp put name=titlevalue=Title.jsp/ put name=body value=/ put name=navigation value=Nav.jsp/ /definition !-- Intro page -- definition name=Intro extends=Wizard put name=bodyvalue=workflow/intro/intro.jsp/ /definition Here, the wizardLayout.jsp is solely responsible, as the name suggests, for laying out the various tiles using necessary HTML tags. The problem with this strategy is that by separating the body and nav into separate tiles limits the use of the Struts html:form tag. Firstly, the begin and end form tag must be in the same JSP. This prevents the tag from beginning in the 'body' tile and ending in the 'navigation' tile. There are other complications, even if I'm willing to compromise the design and place the html:form tag in the layout page (wizardLayout.jsp above). This would require some convoluted JavaScript that sets the form's action attribute on each page. The only workaround I have found is to have the body the navigation in the same tile; in other words -- not have a 'navigation' tile at all. This has a serious shortcoming in that it forces every body panel (i.e. every page in the wizard) to have knowledge of layout and therefore responsible for its maintenance. I really like the concept of Tiles and would love to use it to its fullest. Do you have any suggestions? Am I missing something fundamental? Sri -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts + Tiles: Design Question
Cedric, You are right on the point. I been using this strategies over and over again to share from amon difference action. I works well for me, plus I really hate having JavaScript or hidden field to indicate which action your are intended to submit. I think this is the right way to do cuz you really do separate the controller logic from presentation logic, or you can say .. hidding the controller logic by abstracting the presentation. danny -Original Message- From: Cedric Dumoulin [SMTP:[EMAIL PROTECTED]] Sent: Friday, May 24, 2002 3:19 AM To: Struts Users Mailing List Subject: Re: Struts + Tiles: Design Question There is several strategies. Are you sure that you need one single form for navigation and body ? * If navigation and body aren't related, you can put several forms, only one will be selected by browser when submitting. * If navigation and body are related, you need a common ancestor in the Tiles philosophy. A common ancestor is a tiles that will insert related sub-tiles. This ancestor contains the form, and sub-tiles contains form's elements. In your case, you can have an ancestor body playing this role, and inserting the navigation and real body Hope this help, Cedric Sri Sankaran wrote: Struts version: 1.0.2 Servlet engine: Tomcat 4.0.2 I am trying to build a wizard framework using Tiles. It follows the standard Windows wizard metaphor with a body panel and navigation buttons below. I am running into a problem and would like any opinions/suggestions. A logical use of Tiles would call for the body and nav buttons to be separate tiles that are combined using the tileDefinitions file. For example: definition name=Wizard path=/wizardLayout.jsp put name=titlevalue=Title.jsp/ put name=body value=/ put name=navigation value=Nav.jsp/ /definition !-- Intro page -- definition name=Intro extends=Wizard put name=bodyvalue=workflow/intro/intro.jsp/ /definition Here, the wizardLayout.jsp is solely responsible, as the name suggests, for laying out the various tiles using necessary HTML tags. The problem with this strategy is that by separating the body and nav into separate tiles limits the use of the Struts html:form tag. Firstly, the begin and end form tag must be in the same JSP. This prevents the tag from beginning in the 'body' tile and ending in the 'navigation' tile. There are other complications, even if I'm willing to compromise the design and place the html:form tag in the layout page (wizardLayout.jsp above). This would require some convoluted JavaScript that sets the form's action attribute on each page. The only workaround I have found is to have the body the navigation in the same tile; in other words -- not have a 'navigation' tile at all. This has a serious shortcoming in that it forces every body panel (i.e. every page in the wizard) to have knowledge of layout and therefore responsible for its maintenance. I really like the concept of Tiles and would love to use it to its fullest. Do you have any suggestions? Am I missing something fundamental? Sri -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts + Tiles: Design Question
I am unable to use a common ancestor because some tags (such as html:select, html:radio) must be nested in a form and it doesn't recognize that this is indeed the case: Layout-Begin html:form .. Body-Tile-Begin html:radio Body-Tile-End .. Nav-Tile-Begin Previous-button Next-button .. Nav-Tile-End /html:form Layout-End So, I am forced to have the form tag in the Body-Tile. Even then I am forced to use JavaScript to indicate which of the buttons in the Nav-Tile was pressed. Could you elaborate on how you workaround it? Sri -Original Message- From: Trieu, Danny [mailto:[EMAIL PROTECTED]] Sent: Friday, May 24, 2002 11:33 AM To: 'Struts Users Mailing List' Subject: RE: Struts + Tiles: Design Question Cedric, You are right on the point. I been using this strategies over and over again to share from amon difference action. I works well for me, plus I really hate having JavaScript or hidden field to indicate which action your are intended to submit. I think this is the right way to do cuz you really do separate the controller logic from presentation logic, or you can say .. hidding the controller logic by abstracting the presentation. danny -Original Message- From: Cedric Dumoulin [SMTP:[EMAIL PROTECTED]] Sent: Friday, May 24, 2002 3:19 AM To: Struts Users Mailing List Subject: Re: Struts + Tiles: Design Question There is several strategies. Are you sure that you need one single form for navigation and body ? * If navigation and body aren't related, you can put several forms, only one will be selected by browser when submitting. * If navigation and body are related, you need a common ancestor in the Tiles philosophy. A common ancestor is a tiles that will insert related sub-tiles. This ancestor contains the form, and sub-tiles contains form's elements. In your case, you can have an ancestor body playing this role, and inserting the navigation and real body Hope this help, Cedric Sri Sankaran wrote: Struts version: 1.0.2 Servlet engine: Tomcat 4.0.2 I am trying to build a wizard framework using Tiles. It follows the standard Windows wizard metaphor with a body panel and navigation buttons below. I am running into a problem and would like any opinions/suggestions. A logical use of Tiles would call for the body and nav buttons to be separate tiles that are combined using the tileDefinitions file. For example: definition name=Wizard path=/wizardLayout.jsp put name=titlevalue=Title.jsp/ put name=body value=/ put name=navigation value=Nav.jsp/ /definition !-- Intro page -- definition name=Intro extends=Wizard put name=bodyvalue=workflow/intro/intro.jsp/ /definition Here, the wizardLayout.jsp is solely responsible, as the name suggests, for laying out the various tiles using necessary HTML tags. The problem with this strategy is that by separating the body and nav into separate tiles limits the use of the Struts html:form tag. Firstly, the begin and end form tag must be in the same JSP. This prevents the tag from beginning in the 'body' tile and ending in the 'navigation' tile. There are other complications, even if I'm willing to compromise the design and place the html:form tag in the layout page (wizardLayout.jsp above). This would require some convoluted JavaScript that sets the form's action attribute on each page. The only workaround I have found is to have the body the navigation in the same tile; in other words -- not have a 'navigation' tile at all. This has a serious shortcoming in that it forces every body panel (i.e. every page in the wizard) to have knowledge of layout and therefore responsible for its maintenance. I really like the concept of Tiles and would love to use it to its fullest. Do you have any suggestions? Am I missing something fundamental? Sri -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts + Tiles: Design Question
Ahaaa.. ic what you are trying to do. What I was saying is that you can have multiple page that share teh same from and each page submit the a different action ... for example ...the CRUD ...'C'-create and 'U'-update, are to different page that share the same from.. where as in you case it is different ... you are actualy only have one page and one form so there is no need to have a common ancestor all you need is to have a hidden field that indicate whether your form submition is 'Prev' or 'Next' and have your nav button modify this hidden field before submittion. -Original Message- From: Sri Sankaran [SMTP:[EMAIL PROTECTED]] Sent: Friday, May 24, 2002 9:37 AM To: 'Struts Users Mailing List' Subject: RE: Struts + Tiles: Design Question I am unable to use a common ancestor because some tags (such as html:select, html:radio) must be nested in a form and it doesn't recognize that this is indeed the case: Layout-Begin html:form .. Body-Tile-Begin html:radio Body-Tile-End .. Nav-Tile-Begin Previous-button Next-button .. Nav-Tile-End /html:form Layout-End So, I am forced to have the form tag in the Body-Tile. Even then I am forced to use JavaScript to indicate which of the buttons in the Nav-Tile was pressed. Could you elaborate on how you workaround it? Sri -Original Message- From: Trieu, Danny [mailto:[EMAIL PROTECTED]] Sent: Friday, May 24, 2002 11:33 AM To: 'Struts Users Mailing List' Subject: RE: Struts + Tiles: Design Question Cedric, You are right on the point. I been using this strategies over and over again to share from amon difference action. I works well for me, plus I really hate having JavaScript or hidden field to indicate which action your are intended to submit. I think this is the right way to do cuz you really do separate the controller logic from presentation logic, or you can say .. hidding the controller logic by abstracting the presentation. danny -Original Message- From: Cedric Dumoulin [SMTP:[EMAIL PROTECTED]] Sent: Friday, May 24, 2002 3:19 AM To: Struts Users Mailing List Subject:Re: Struts + Tiles: Design Question There is several strategies. Are you sure that you need one single form for navigation and body ? * If navigation and body aren't related, you can put several forms, only one will be selected by browser when submitting. * If navigation and body are related, you need a common ancestor in the Tiles philosophy. A common ancestor is a tiles that will insert related sub-tiles. This ancestor contains the form, and sub-tiles contains form's elements. In your case, you can have an ancestor body playing this role, and inserting the navigation and real body Hope this help, Cedric Sri Sankaran wrote: Struts version: 1.0.2 Servlet engine: Tomcat 4.0.2 I am trying to build a wizard framework using Tiles. It follows the standard Windows wizard metaphor with a body panel and navigation buttons below. I am running into a problem and would like any opinions/suggestions. A logical use of Tiles would call for the body and nav buttons to be separate tiles that are combined using the tileDefinitions file. For example: definition name=Wizard path=/wizardLayout.jsp put name=titlevalue=Title.jsp/ put name=body value=/ put name=navigation value=Nav.jsp/ /definition !-- Intro page -- definition name=Intro extends=Wizard put name=bodyvalue=workflow/intro/intro.jsp/ /definition Here, the wizardLayout.jsp is solely responsible, as the name suggests, for laying out the various tiles using necessary HTML tags. The problem with this strategy is that by separating the body and nav into separate tiles limits the use of the Struts html:form tag. Firstly, the begin and end form tag must be in the same JSP. This prevents the tag from beginning in the 'body' tile and ending in the 'navigation' tile. There are other complications, even if I'm willing to compromise the design and place the html:form tag in the layout page (wizardLayout.jsp above). This would require some convoluted JavaScript that sets the form's action attribute on each page. The only workaround I have found is to have the body the navigation in the same tile; in other words -- not have a 'navigation' tile at all. This has a serious shortcoming in that it forces every body panel (i.e. every page in the wizard) to have knowledge of layout and therefore responsible for its maintenance. I really like the concept of Tiles and would love to use it to its fullest. Do you have any suggestions? Am I missing something fundamental? Sri
Struts + Tiles: Design Question
Struts version: 1.0.2 Servlet engine: Tomcat 4.0.2 I am trying to build a wizard framework using Tiles. It follows the standard Windows wizard metaphor with a body panel and navigation buttons below. I am running into a problem and would like any opinions/suggestions. A logical use of Tiles would call for the body and nav buttons to be separate tiles that are combined using the tileDefinitions file. For example: definition name=Wizard path=/wizardLayout.jsp put name=titlevalue=Title.jsp/ put name=body value=/ put name=navigation value=Nav.jsp/ /definition !-- Intro page -- definition name=Intro extends=Wizard put name=bodyvalue=workflow/intro/intro.jsp/ /definition Here, the wizardLayout.jsp is solely responsible, as the name suggests, for laying out the various tiles using necessary HTML tags. The problem with this strategy is that by separating the body and nav into separate tiles limits the use of the Struts html:form tag. Firstly, the begin and end form tag must be in the same JSP. This prevents the tag from beginning in the 'body' tile and ending in the 'navigation' tile. There are other complications, even if I'm willing to compromise the design and place the html:form tag in the layout page (wizardLayout.jsp above). This would require some convoluted JavaScript that sets the form's action attribute on each page. The only workaround I have found is to have the body the navigation in the same tile; in other words -- not have a 'navigation' tile at all. This has a serious shortcoming in that it forces every body panel (i.e. every page in the wizard) to have knowledge of layout and therefore responsible for its maintenance. I really like the concept of Tiles and would love to use it to its fullest. Do you have any suggestions? Am I missing something fundamental? Sri -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts + Tiles: Design Question
Just a quick suggestion. Couldn't you use javascript in your nav.jsp to submit the form in the intro.jsp? Or do you need form fields in the nav.jsp? Graham - Original Message - From: Sri Sankaran [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 22, 2002 2:53 PM Subject: Struts + Tiles: Design Question Struts version: 1.0.2 Servlet engine: Tomcat 4.0.2 I am trying to build a wizard framework using Tiles. It follows the standard Windows wizard metaphor with a body panel and navigation buttons below. I am running into a problem and would like any opinions/suggestions. A logical use of Tiles would call for the body and nav buttons to be separate tiles that are combined using the tileDefinitions file. For example: definition name=Wizard path=/wizardLayout.jsp put name=titlevalue=Title.jsp/ put name=body value=/ put name=navigation value=Nav.jsp/ /definition !-- Intro page -- definition name=Intro extends=Wizard put name=bodyvalue=workflow/intro/intro.jsp/ /definition Here, the wizardLayout.jsp is solely responsible, as the name suggests, for laying out the various tiles using necessary HTML tags. The problem with this strategy is that by separating the body and nav into separate tiles limits the use of the Struts html:form tag. Firstly, the begin and end form tag must be in the same JSP. This prevents the tag from beginning in the 'body' tile and ending in the 'navigation' tile. There are other complications, even if I'm willing to compromise the design and place the html:form tag in the layout page (wizardLayout.jsp above). This would require some convoluted JavaScript that sets the form's action attribute on each page. The only workaround I have found is to have the body the navigation in the same tile; in other words -- not have a 'navigation' tile at all. This has a serious shortcoming in that it forces every body panel (i.e. every page in the wizard) to have knowledge of layout and therefore responsible for its maintenance. I really like the concept of Tiles and would love to use it to its fullest. Do you have any suggestions? Am I missing something fundamental? Sri -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts + Tiles: Design Question
Graham: JavaScript does present an alternative. The problem I have with JavaScript in the Struts context is that it tightly couples the contents of the struts-config to the JSP. For example, to submit the form, you have to know the name of the form (unless you have just one or can make other simplifying assumptions). The name of the form itself is driven by the 'name' attribute of the action-mapping element in the struts-config. Having said that, this may be the lesser of two evils. I just have to remember if any mapping information changes to make sure that related pages are modified as well. Thanks Sri -Original Message- From: Graham Lounder [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 22, 2002 2:07 PM To: Struts Users Mailing List Subject: Re: Struts + Tiles: Design Question Just a quick suggestion. Couldn't you use javascript in your nav.jsp to submit the form in the intro.jsp? Or do you need form fields in the nav.jsp? Graham - Original Message - From: Sri Sankaran [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 22, 2002 2:53 PM Subject: Struts + Tiles: Design Question Struts version: 1.0.2 Servlet engine: Tomcat 4.0.2 I am trying to build a wizard framework using Tiles. It follows the standard Windows wizard metaphor with a body panel and navigation buttons below. I am running into a problem and would like any opinions/suggestions. A logical use of Tiles would call for the body and nav buttons to be separate tiles that are combined using the tileDefinitions file. For example: definition name=Wizard path=/wizardLayout.jsp put name=titlevalue=Title.jsp/ put name=body value=/ put name=navigation value=Nav.jsp/ /definition !-- Intro page -- definition name=Intro extends=Wizard put name=bodyvalue=workflow/intro/intro.jsp/ /definition Here, the wizardLayout.jsp is solely responsible, as the name suggests, for laying out the various tiles using necessary HTML tags. The problem with this strategy is that by separating the body and nav into separate tiles limits the use of the Struts html:form tag. Firstly, the begin and end form tag must be in the same JSP. This prevents the tag from beginning in the 'body' tile and ending in the 'navigation' tile. There are other complications, even if I'm willing to compromise the design and place the html:form tag in the layout page (wizardLayout.jsp above). This would require some convoluted JavaScript that sets the form's action attribute on each page. The only workaround I have found is to have the body the navigation in the same tile; in other words -- not have a 'navigation' tile at all. This has a serious shortcoming in that it forces every body panel (i.e. every page in the wizard) to have knowledge of layout and therefore responsible for its maintenance. I really like the concept of Tiles and would love to use it to its fullest. Do you have any suggestions? Am I missing something fundamental? Sri -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
