aspose file tools*
The moose likes Struts and the fly likes do i have to use session here ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Frameworks » Struts
Bookmark "do i have to use session here ?" Watch "do i have to use session here ?" New topic

do i have to use session here ?

Raj Bhandari
Ranch Hand

Joined: Oct 19, 2005
Posts: 97
Hi all,

In my application, I have a update page.. where I show some text boxes to the user to edit and I have a history section which shows some list of records (this list is just read-only) and I display them by using struts logic:iterate.
Now my problem is that when I implement struts server side validation and suppose there are some errors after user presses submit, he is taken back to the same page with the error messages but this time I lose my history list. I understand that struts posts back the data in text boxes etc but not something which is not in a html field (like my history list). What should I do in such a case to display the list then when error is thrown back ?
Do you suggest saving the whole formbean in session (i would hate to do that bcos of session mgmt issues) or hitting the database again to get that history list?
Is there a better/simpler/more efficient way out ?
Tks a lot!
Jeanne Boyarsky
internet detective

Joined: May 26, 2003
Posts: 30551

If the history list contains simple data, you could put it in the form that is submitted to the request each time by using hidden input tags.

[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Merrill Higginson
Ranch Hand

Joined: Feb 15, 2005
Posts: 4864
If you don't want to put this data in the session, I'd suggest you simply get it again from the database. Most relational databases have a caching mechanism, so getting the records the second time from the database should probably be quite fast.

Consultant, Sima Solutions
Chris Boldon
Ranch Hand

Joined: Aug 10, 2006
Posts: 190
I'll try my spin on it, how I'd handle it.

Give each user a 'history' which is stored in the db.
That is to say, each history is associated with a user.

Then implement a cacheing system such as eh-cache.

Specifying hidden values is fine, but may present some security issues. Many development toolkits allow you to alter values on forms.

Some DBs do have a caching system, but this ties you to a specific database.

This way when a user comes back, their history is still stored.
Raj Bhandari
Ranch Hand

Joined: Oct 19, 2005
Posts: 97
Thank you everyone for your replies.
Here are my concerns:

Jeanne mentioned that I could put the data in hidden fields too - Actually I simplified my problem and mentioned only one history section.. infact I have many different such history sections in one jsp itself and I have many jsps with the same problem.. so this is lots of extra work.

Merrill's suggestion is one of the options I have been considering.. not very sure yet what route I'll take.. I just was curious to know if others do it differently

Chris, I'm not clear about your solution.. do I really need to associate a 'history' with a user because my history doesn't have to do anything with the user.. but history about the entity the user is trying to update. Please let me know if I misunderstood.

Another option (not sure how good it is) I'm considering is putting client-side validation (javascript) on the front so that basic server-side validation never needs to happen.. but this will still not work if in future I need to do server side business logic validation and throw the error back.

Any other ideas ?
Chris Boldon
Ranch Hand

Joined: Aug 10, 2006
Posts: 190
It seems like you have a history that needs to persist. I guess the big question is how long do you want this history to persist. Do you want a new history for each entity for each user? Do you want a new history for each entity for all users?

Maybe if you could give some insite into how this app works we could give you a better answer. The idea I gave you is how we work shopping carts in eBusiness. That way if a user times out and comes back, they still have their cart. If they put something in their cart a week ago and come back it is still there.
Raj Bhandari
Ranch Hand

Joined: Oct 19, 2005
Posts: 97
Hi Chris,

I think the word 'history' is causing confusion here.. let me explain again.
Say I have a jsp to enter contact information for a manager in a company:

company name (textbox)
contact name (textbox)
contact phone (textbox)

There will also be a 'History' section which tells who all were the managers in that company before... something like:

firstname lastnamephoneno datestartdateend
-------- ---------------- ----------------


So basically, I'm losing the history list when I throw the error back.
Chris Boldon
Ranch Hand

Joined: Aug 10, 2006
Posts: 190
So you enter the company, and then something is populated showing the history of that company. Whether it be an auto-complete suggest, a field, a div, etc?

I'd use eh-cache. We've had a similar problem in the past, though it was with user timeout.

Remember to update the database and the cache at the same time when a new line item is added.

If the errors being thrown are caught non-fatal exceptions, you could handle the errors yourself. For instance, send them out to a hidden div on the page the user is currently on, which is then displayed. That way the data would not be thrown away.
Arulanand Dayalan
Ranch Hand

Joined: Aug 10, 2005
Posts: 124
Why dont you try Ajax. If its going to be an Simple Server Side Validation without involving any complex logic then this is preferable and more clean. There would be no need for you to hit the db, store the values in session or as hidden parameters.

Hope this helps.

Brent Sterling
Ranch Hand

Joined: Feb 08, 2006
Posts: 948
I use an approach similar to that mentioned my Merrill. While loading a list every time the page refreshes seems like a bit of overhead, it is likely that the actually processing time will be measure in the hundredths of a second (provided that the query is fast, you are loading less than 100 records and you don't need to perform intensive business logic on the data).

- Brent
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
subject: do i have to use session here ?