Form Beans necessary?

[Gregg Bolinger]

Ok, while working on my web app I have several JSP pages that are forms. I submit these forms to the appropriate Servlet for handling.
Now, what about a Bean for these forms? Should I be using Form Beans for every form? Do I populate the Form bean in the Servlet I submit the Form to, or should I be calling ALL my JSP's from another Servlet that creates the Bean?
I know about the Jakarta FormBeans/DynaBeans libraries, but for the sake of learning, I don't want to use those.
Thanks.

[Pradeep bhatt]

Now, what about a Bean for these forms? Should I be using Form Beans for every form? Do I populate the Form bean in the Servlet I submit the Form to, or should I be calling ALL my JSP's from another Servlet that creates the Bean?

What is the problem?

[Gregg Bolinger]

There is not a problem. I am just wondering about standards. If I do any validation on the server side, I would like to be able to retain values on the Form so that is why I think I might need a Form Bean for my forms. But I am just curious as to what the norm is for this process. Primarily:
Do I populate the Form bean in the Servlet I submit the Form to, or should I be calling ALL my JSP's from another Servlet that creates the Bean?

[Pradeep bhatt]

So, you do not wnat to use the automatic Form bean population provided by struts? ok
I assume that you are using a single controller servlet and this call action classes.you can use action classes for bean population.

[Gregg Bolinger]

I am not using a single controller servlet. For every JSP page I have a corrosponding Servlet that handles the request. It's as simple as it gets.

[Pradeep bhatt]

I suggest that you read FrontController design pattern
http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html

[Gregg Bolinger]

Originally posted by Pradeep Bhat:
I suggest that you read FrontController design pattern
http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html

Thanks for the fairly typical Sun Article. Some diagrams and a bunch of code with no explination of what the code does.
That still doesn't really answer my question though. If I use a front controller of some sort, do I instantiate my bean there and load it with the values from the JSP Form? Or do they get loaded in the Servlet I actually do the work in?
What if I don't want to use a front controller? Where do I populate my Form bean with the values from the Form? In the Servlet I submit to?
Hmm, sounds like my original question.

[Bear Bibeault]

As you might of guessed from previous postings, I'm not Struts' number one fan. I think it's a great idea; I'm just less than enthusiastic with its implementation.
So what does this have to do with your question?
Well, in all my web apps I do use the single Front Controller pattern mentioned in previous responses (basically, I implemented a web app framework similar in concept to Struts, but that does things in a way that I'm happier with). In this framework, submitted form data is abstracted into a 'form bean' (as you call them) to be passed to the command action for processing. This same bean can be used when forwarded to a page to pre-populate corresponding html form fields.
I see no reason that this sort of thing couldn't be useful in a non-single controller pattern like your system. Rather than having the lion's share of the code in each servlet deal with casting and converting request params, delegate that responsibility to a 'form bean' that can process the data and abstract it on behalf of your servlet.
In this case, your servlet would be repsonsible for initiating this process (rather than the single front controller in my world).
Now, how 'standard' this is in the non-Struts world, I have no idea. But it works well for me.
hth,
bear

[Lasse Koskela]

Let's turn the question around: where you should not populate a FormBean?
- JSP is out of the question because you don't want to mess up your pretty rendering stuff with some ugly request.getParameter() stuff.
- Servlet is out of the question because you shouldn't do anything more than necessary in a servlet (generally speaking, it should delegate everything else but simple HTTP request/response processing).
That leaves... Hmm... Helper classes which the servlet invokes for creating a FormBean instance for you. Now the question arises how do you know which FormBean to create? If you have one servlet per JSP, you can just hard code the FormBean implementation class into the servlet. If you use a single front controller, you'll need to use some configuration file for telling which request URIs call for which FormBean.

[Pradeep bhatt]

I would use something like Action classes for e.g. for login
authenticateUser etc and populate the bean there.

[Craig Jackson]

I will put my $0.02 in. It's been awhile so bear with me. I guess what you are asking is that, who should be responsible for creating and populating the form bean with data, so as to keep usability high and maintainability low. The servlet or the route all jsp through one servlet, which also will populate the form bean. I quess one question you might want to ask yourself is who has the information to populate the form bean. I would think that would be the jsp page. So in my opinion I would create the bean in the jsp page populate the form bean with the data, route the request to the controller servlet which will access the form bean (probably from the session/request state). Depending on the results of the validation, If validation is good I will forward my request/response to another jsp else I will forward the request/response to an error page which will access the formbean displaying the incorrect form entries and start all over again. Thus you have made the formbean a value object or data object. In my opinion you have the kept the cohesion high and coupling low on the jsp page(it's only doing one thing, capturing data) and the form bean can be used for all of your different forms. The servlet can just be used as the controller.
Like I said this is one persons opinion. I hope understood your question or at least come close. There are different design patterns that you may want to investigate, that may fit what your are trying to do.
craig.