• Post Reply Bookmark Topic Watch Topic
  • New Topic

best approach to send data from a selected row of a table  RSS feed

 
Jorge Blaz
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I want to select a row from a table in a jsp and send the data asociated to this row to a servlet.
A servlet builds an ArrayList that contains objects of a defined type.
This arraylist object is put in the request and a jsp is called.
The jsp access the arraylist and writes a table where the elements of the arraylist will be the rows of the table (with a column for each of the object properties)
The user can select a row by clicking on a radiobutton that appears on each row.The data of the row selected should be sent to the servlet in the next http request.
So, I've thinking of two approaches:
1) Build the radiobuttons so that when clicked a javascript function is called that takes as parameters every value of each column of the selected row.
The javascript function put these values to the equivalent hiddens (input elements of the form).
When the submit button is clicked, the hidden fields will contain the data from the selected row.
2) Each radiobutton is given a value that is the position of the object within the arraylist of objects.
Then, you set the arraylist on session scope and you only send the value of the radiobutton in the request.
The servlet then gets this value and access this position in the Arraylist to get the object and that means the values of the selected row.
Which one is the best approach if you use JSTL+EL in the JSP pages?
Thanks in advance.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66153
146
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sending all the data back and forth as you outlined in approach 1 is not a good idea for many reasons, not the least of which is the ease with which it can be spoofed.
I would use a variation of your second approach.
I would assign the value of a unique key (the primary key of the record if the objects represent database records) to the radio control rather than an ordinal into the array.
[ April 23, 2004: Message edited by: Bear Bibeault ]
 
Jorge Blaz
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, the primary key of the database table would be a great value for the radio buttons. But my question is: It is good practise to put the objet on session scope so that the servlet has access to it to select the appropiate object depednding on the radio button value?.
Is there another way to do it without having to put the object on session scope?
Thanks.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66153
146
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's a good question. And like all good questions has no pat answer. The short, unsatisfying answer is: it depends.
But what does it depend on?
Firstly, are you sure that you need to cache the data in memory to being with, or are you falling victim to "premature optimization"? I see a lot of knee-jerk reactions that always assume that going back to the database is a bad thing. Not necessarily so. That, after all, is what databases do. Most databases are optimized for fast lookup; especially if the schema is well thought out and the tables are indexed appropriately.
So one approach could be to simply go back to the database with the primary key and fetch the data when the form is submitted. Then if you detect a problem with overloading the database, or the lookup time is too slow for your liking, you can consider caching the data in memory.
If you do so, there are a number of issues that need to be dealt with. Firstly, how to prevent the cached data from getting "stale" -- in other words, out-of-date with what is in the db.
If your app is the only means by which the db can be updated, then operations that modify the db can invalidate the cached objects as appropriate. If the db can be changed outside the control of your app you may need to institute an expiration duration for cached objects so that they have the opportunity to refresh themselves from the db periodically. If the db doesn't change often or at all, "staleness" may not even be an issue.
Then we actually come to your question as to where the best place to put the cache is. Session scope would be an appropriate choice if the cached data is user-specific. If, however, the data is non-user-specific, application scope might be a better place for the cached objects.
 
Jorge Blaz
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Bear Bibeault:

So one approach could be to simply go back to the database with the primary key and fetch the data when the form is submitted. Then if you detect a problem with overloading the database, or the lookup time is too slow for your liking, you can consider caching the data in memory.

Yes, i like this approach. It would left the JSP cleaner without the Javascript and there would not be necessary to store the object on session scope, with the problems that it will represent as you have stated.
So, maybe the data that's useful to store in session scope could be data that is not going to change during the session like user preferences (userid) or language preferences. This way all the JSPs and Java classes will have access to these values. Is that done this way usually?
Originally posted by Bear Bibeault:

If your app is the only means by which the db can be updated, then operations that modify the db can invalidate the cached objects as appropriate. If the db can be changed outside the control of your app you may need to institute an expiration duration for cached objects so that they have the opportunity to refresh themselves from the db periodically. If the db doesn't change often or at all, "staleness" may not even be an issue.
Then we actually come to your question as to where the best place to put the cache is. Session scope would be an appropriate choice if the cached data is user-specific. If, however, the data is non-user-specific, application scope might be a better place for the cached objects.

Very informative and helpful. Thanks for the reply, Bear.
 
Joe Pardi
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree, only exchange the primary key of the row being operated on by the user. This makes for a small message to the server.
For rendering the grid, take a lok at this library:
http://www.dotjonline.com
If you're not into commercial solutions, minimally it will give you some ideas.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!