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!
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.
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.
Joined: Oct 19, 2005
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.
Any other ideas ? Tks!
Joined: Aug 10, 2006
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.
Joined: Oct 19, 2005
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:
So basically, I'm losing the history list when I throw the error back. Tks
Joined: Aug 10, 2006
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.
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.
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).