I'm starting work on a new project that has well into construction. As I'm looking through the code base, I'm trying to take in the existing design so that I can more thoroughly understand the application. I've run across a practice that I'm not so sure I agree with and I wanted to bounce it off some other folks that may have had more experience with
Struts and
JSP's. (By the way, if this is more of a Struts question than a JSP question, feel free to move this post.)
When using Struts, all of the form parameters are encapsulated in a Form Bean (an object that extends ActionForm). In general, my concept of a Form Bean was to encapsulate the form data and do validation on that data. In addition, the Form Bean serves a wonderful purpose when the user enters an error. In that case, it's common that execution will be sent back to the same screen the user was just on but it will display an error message so that the user can correct what was wrong and resubmit the form. You can then use the Form Bean to repopulate the form (with the data the user had previously submitted), like this:
However, in this new application, I'm finding that the Form Bean is also being used to encapsulate model information.
For example, a call is made to a database to retrieve a list of locations. Then, in order to get that information to the view, the list is put into the Form Bean. Then, from the JSP, you can do something like this (note that the locations are put into the Form Bean under the member name "siteNames"):
This works, but it feels wrong to me. Am I just naive to the way Struts is supposed to work (this is my first full-fledged Struts app I've worked with)? I would have thought the model information would have been put into some other
Java object (probably a Java Bean) and that object would have been explicity put into the request for JSP access.
I guess I'm just not sure if I'm comfortable with Form Beans being used in this way. Any comments?
Edited by Corey McGlone: Turned off smilies to keep them from interfering with my jsp tags.
[ October 28, 2004: Message edited by: Corey McGlone ]