A few questions regarding dropdown lists in JSP

[John Paul Hoey]

Hi All,

[I have edited my initial question to this shorter one]

Basically, whats the best way to retain form data between multiple JSPs without using a submit button?

Essentially, when a user selects a value from a drop down list on one of the JSPs which populated multiple entries within a form, I want this selected data to be 'retained' between different JSPs until such time the user is happy with what they have selected. At which point the user can opt to 'submit' their selections from one of the JSPs - this is the only page to contain a submit button.

Is JavaBeans the way to go? I recently read that using JavaBeans with Servlets doesnt really conform to the correct standard. Ideally, if someone could advise if this is possible by only using JSTL along with session scope variables then that would be appreciated.

Hopefully my questions make sense however if not then please dont hesitate to let me know

Thanks in Advance

John Paul

[John Paul Hoey]

Hi All,

I 'think' I have figured out my question therefore I am marking this as resolved.

Cheers

[K. Tsang]

Hi John. So what did you do to solve your problem?

From your initial post, storing such in session scope is one way, Java bean could be another.

[John Paul Hoey]

Hi K. Tsang,

I decided to go with session scope however can I ask what is the preferred way to store data between JSP and Servlets? Is it to use JavaBeans or to use Session scope? Is there a benefit to one over the other? Or is it subjective?

Thanks in advance

[Bear Bibeault]

John Paul Hoey wrote:I recently read that using JavaBeans with Servlets doesnt really conform to the correct standard.

Hogwash. Beans are used extensively in web apps, especially in communicating between the servlet controllers and JSPs.

Ideally, if someone could advise if this is possible by only using JSTL along with session scope variables then that would be appreciated.

Not sure what you mean by "only". Web technologies are used in concert.

[Bear Bibeault]

John Paul Hoey wrote:I decided to go with session scope however can I ask what is the preferred way to store data between JSP and Servlets?

It depends. Session scope should only be used for longer-term storage. Communications between a page controller and its JSP usually employs request scope. Your reliance on session scope may be an indication of a fundamental design problem.

Is it to use JavaBeans or to use Session scope? Is there a benefit to one over the other?

"or"? It's not an either or. You can store any objects you want in the various scopes. Whether the objects are beans or not is irrelevant. In fact, most of the time, they will be.

Your question is like asking "Which should I use: an egg crate, or eggs?" The session scope (and other scopes) are containers, beans are just one of the things you can put into the containers.

I'm getting a feeling that there's a fundamental misunderstanding going on here, but I don't have enough info to pin it down. Statements like the above are a clear red flag though.

[John Paul Hoey]

Hi Bear,

Thanks for your response.

Hogwash. Beans are used extensively in web apps, especially in communicating between the servlet controllers and JSPs.

Yeah I was getting confused here. What I was actually meaning was in relation to the statement:

Do NOT use <jsp:useBean> if you're already using a servlet to process the model. It will only lead to confusion and maintenance trouble because the <jsp:useBean> follows a different level of MVC approach than when you're using servlets. It's either servlets or <jsp:useBean>, not both

Which it states at the bottom of the following link:

Stack Overflow - Servlets

This now makes sense to me.

Thanks again.

[Bear Bibeault]

Right. The useBean tag has very limited use in the past 13 years after the introduction of the JSTL and EL. In general, it's superfluous and should not be used.

But that has nothing to do with the use of beans themselves; just with the use of that tag (and its brethren such as getProperty and setProperty).