very common form functionality

hi,
its very common situation i am in.

first jsp which has a 1st part of form, and i next button.
second jsp which has 2nd part of form, and i next button.
third jsp which shows the data of form (review screen), and a submit button.
4th jsp which shows confirmation screen, form data is stored in database.

two approaches i can think of:

1. submit first jsp to a servlet, servlet keeps data in session, forward request to second jsp, second jsp submits form to servlet, it stores 2nd set of data in session, and forward request to 3rd jsp, 3rd jsp fetches data from session and displays, 4th jsp also gets data from session and strores it into database.

pros: easy to imeplement
cons: unncessary using session

2. first jsp submits to servlet, it does some validation, sends data to 2nd jsp, it stores data in hidden field, capture 2nd set of data and submits to servlet, again some validation, sends data to 3rd jsp, it stores all previous data in hidden field of form, shows data...

pros: but complex
cons: no session involved

what you guys suggest?

thanks.

It really depends on how much data and how many users you are talking about. I don't think there is going to be any clear answer.

pooja jain wrote:cons: unncessary using session

That's not much of a con.

And how would you characterize this as "unncessary"?

Either is a viable approach. Choose the one that seems the most natural to your structure.

Jeanne Boyarsky wrote:It really depends on how much data and how many users you are talking about. I don't think there is going to be any clear answer.

data: around 10-12 fields per page, so total 20-25.
user: this is interesting. what if its 1000, what if its 10000, what if its 100000 or more?

Bear Bibeault wrote:

pooja jain wrote:cons: unncessary using session

Either is a viable approach. Choose the one that seems the most natural to your structure.

i didn't get this.

That's not much of a con.

And how would you characterize this as "unncessary"?

because we have the other option that saves session.

pooja jain wrote:because we have the other option that saves session.

Save it from what? Why does it need saving?

Bear Bibeault wrote:

pooja jain wrote:because we have the other option that saves session.

Save it from what? Why does it need saving?

session should be as small as possible. so if we use second one, we are good.

Are you talking about megabytes of data?

The amount of data you are likely to be talking about with form submissions is negligible. You should not avoid using the session for things for which it is intended and for which it makes sense.

This is one of those cases.

Hi Pooja,

I would not suggest the first approach as loading the session with such huge data is not adviable. The best approach will be request-response. but you have to tke care of back button, reset, parent child especially in case of pop ups etc. One major look out for session is to think if it is really necessary to have so many variables in the session scope. You also need to think abt concurrency and session replication in server. Think of using struts when you have many such flows. hope this helps..

Regards,
Acharya

Acharya Thiyagarajan wrote:I would not suggest the first approach as loading the session with such huge data is not adviable.

Again, we are not talking about "huge data" here. There seems to be a prejudice against using the session in some circles which is nothing short of ridiculous. It's a tool like any other, and used wisely is not something to be avoided.

It's a common novice mistake to take admonitions to be sure and use the session wisely as "don't use the session". Don't fall into that trap.

pooja jain wrote:session should be as small as possible. so if we use second one, we are good.

I've seen a benchmark that says sessions should stay under 1KB of data. You are WAY under that.

The number of users matter because it depends how much memory you have. Your data set is so small, I really don't think it matters either way. Do keep in mind you have to re-validate everything on the final form submission because the user can change it on each request - even in a hidden field.

Acharya: How does Struts help with this particular issue? It's just a framework. The form is either in the request or session regardless.