Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

A good design? Opinions please...  RSS feed

 
Winston Smith
Ranch Hand
Posts: 136
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello All,
Assume you have a list of employees stored in a Bean as an ArrayList. Now, a user will have the option of searching this list, navigating forward and backward, and selecting a given employee. Employees are displayed in a normal HTML table, 7 employees at a time. If I were to navigate through the ArrayList, I would have to send the navigation request to another page, update my ArrayList to show the next 7 employees, and return to the original page, this time displaying the new set of 7.
Well, what I've done is create an array of javascript objects which represent "scaled-down" versions of the employee objects in the ArrayList (they contain only info relevant to display). This way, I can freely navigate through the employees without sending requests back to the server each time.
So, is this a good way to go about it, or is it just a hack? Have you done anything like this before?
The main thing I'm worried about is the additional overhead, and perhaps bad design, of creating "javascript versions" of the Bean objects.
Thanks for your suggestions,
WS
 
Mark Latham
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Try your working prototype on 3 different versions of Netscape and IE then see if you still think Javascript/DHTML is the way to go. Unless you have a narrowly defined set of browsers you will be required to support, I'd steer clear of a DHTML solution.
And, in general, avoid premature optimization. It's generally true that we developers have a pretty poor track record of predicting where the bottlenecks will be. When we try to solve problems that don't really exist, we often end up with solutions that are unnecessarily complex and difficult to support. A client/server application will have a bunch of round trips between client and server; don't fight it unless it's proven excessive by a performance or scaling problem.
[ December 04, 2003: Message edited by: Mark Latham ]
 
Winston Smith
Ranch Hand
Posts: 136
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, Mark. Fortunately, our customer requires support for IE 4* only, so this has been helpful (the application's use is very limited and in a secure environment). Our main concern is that we want to limit round-trips to the server when performing simple operations like traversing the list (we all know how testy end-users can be).
WS
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Fortunately, our customer requires support for IE 4* only
Always bear in mind that a statement like this is always a trap. I lose count of the number of times I've been assured by a client that I only need to support one browser for an intranet project, because it is the "corporate standard" on all the company machines. What the people making these assurances miss is that corporate standards can and will change. What if next month someone decides to make 1E5, or Mozilla, or Opera the new "corporate standard"? Trust me, it happens a lot.
I've had exactly the same issues on projects where "we only need to make it work with Oracle 7.3.4, because that is the only database approved for use in the company." - until Oracle removes support and the company has to migrate to Oracle 8, or 9, or 10, or DB2 ...
If you have a choice between solutions of roughly equivalent complexity, where one solution ties you to a particular vendor or version of any component, choose the other solution. I hope you'd think twice about hardcoding a numeric "constant" value all through your code, so please think twice about hardcoding a particular browser version all through your code.
Sorry, rant over
 
Mark Latham
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I echo Frank's experience with the client changing their minds about browser requirements. You can almost guarentee it'll happen (and very late in the testing cycle).
Plus keep in mind there are 2 roundtrips that occur... one between the client and app server, and one between the app server and database. By far, the most expensive of the 2 is the roundtrip between the app server and database.
So, why not cache the employee list in the app server's session instead of the clients browser? It's likely that a sub-optimal query is what's actually driving this requirement (otherwise there probably wouldn't be a latency concern). Such a solution wouldn't have the browser specificity of a DHTML approach and will be much easier to support.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!