Users that desire to share how they overcame unexpected or undocumented behavior may do so in this thread. Valid hints/tricks or general useage messages will be added to the manual and or tutorial on future updates. Therefore this thread will serve as a staging area between releases.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Implementing templates as described in the manual may have undesireable behavior under the following circumstances.
1. Action class defines detail section.
2. In struts-config validate=true.
3. In struts-config scope=request.
If the validate method of the formBean returns errors, then the action class never has the opportunity to define the name of the detail section. The result is a blank detail section being displayed.
Work-Arounds
1. Set scope to session, use two action mappings to first load the view without validation and the second one to process user input with validation.
2. An alternate method would be to use the formBean's reset() or validate() method to statically set the detail section's name. The downside of this approach is that the formBean can not be used for multiple detail sections.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If your project is using the templating concept offered in the examples, you may have a need to dynamically populate the properties of the DefaultFormBean. To refresh your memory, the DefaultFormBean holds a set of common properties (header, footer, menu and detail) used by most of the pages in your project. The idea is for each ActionForm to extend the DefaultFormBean.
Recently, I had a need to create a dynamically generated menu based upon a user's permissions; a very common thing to do. This is the solution that I came up with and decided to share.
The first decision was to implement a <div type=xsl> tag for the menu. This tag needs 2 properties in the formBean to support it. Since these properties are the same for every page then they were perfectly suited for the DefaultFormBean.
The xsl source property is static. It simply identifies the name of the xsl file to use for the transformation.
The XmlTableBean property required a bit more attention as it had to be written dynamically to the form bean for each and every page request. I wanted this property to be populated from a session object seamlessly so that no additional programming was needed as new pages were added to the project.
In my first approach I tried to extend the ActionServlet, retrieve the XmlTableBean from the session or create a new one if one did not yet exist in session. This much was easy to do. The problem I ran into is that there is no easy reference to the ActionForm from the ActionServlet. Therefore, I needed another solution.
In my final solution I extended the RequestProcessor and over-rode the processActionForm() method. I first executed the superclass' methed and then checked the ActionForm to see if it was an instance of the DefaultFormBean. If true, I populated the XmlTableBean property with the one in session or created a new one.
In the final analysis, this could be a useful technique whether you are using XView4Struts or not. I hope it helps.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Users that desire to share how they overcame unexpected or undocumented behavior may do so in this thread. Valid hints/tricks or general useage messages will be added to the manual and or tutorial on future updates. Therefore this thread will serve as a staging area between releases.
Implementing templates as described in the manual may have undesireable behavior under the following circumstances.
1. Action class defines detail section.
2. In struts-config validate=true.
3. In struts-config scope=request.
If the validate method of the formBean returns errors, then the action class never has the opportunity to define the name of the detail section. The result is a blank detail section being displayed.
Work-Arounds
1. Set scope to session, use two action mappings to first load the view without validation and the second one to process user input with validation.
2. An alternate method would be to use the formBean's reset() or validate() method to statically set the detail section's name. The downside of this approach is that the formBean can not be used for multiple detail sections.
If your project is using the templating concept offered in the examples, you may have a need to dynamically populate the properties of the DefaultFormBean. To refresh your memory, the DefaultFormBean holds a set of common properties (header, footer, menu and detail) used by most of the pages in your project. The idea is for each ActionForm to extend the DefaultFormBean.
Recently, I had a need to create a dynamically generated menu based upon a user's permissions; a very common thing to do. This is the solution that I came up with and decided to share.
The first decision was to implement a <div type=xsl> tag for the menu. This tag needs 2 properties in the formBean to support it. Since these properties are the same for every page then they were perfectly suited for the DefaultFormBean.
The xsl source property is static. It simply identifies the name of the xsl file to use for the transformation.
The XmlTableBean property required a bit more attention as it had to be written dynamically to the form bean for each and every page request. I wanted this property to be populated from a session object seamlessly so that no additional programming was needed as new pages were added to the project.
In my first approach I tried to extend the ActionServlet, retrieve the XmlTableBean from the session or create a new one if one did not yet exist in session. This much was easy to do. The problem I ran into is that there is no easy reference to the ActionForm from the ActionServlet. Therefore, I needed another solution.
In my final solution I extended the RequestProcessor and over-rode the processActionForm() method. I first executed the superclass' methed and then checked the ActionForm to see if it was an instance of the DefaultFormBean. If true, I populated the XmlTableBean property with the one in session or created a new one.
In the final analysis, this could be a useful technique whether you are using XView4Struts or not. I hope it helps.