File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Servlets and the fly likes Generic Table Maintenance Using Servlets & JSP Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "Generic Table Maintenance Using Servlets & JSP" Watch "Generic Table Maintenance Using Servlets & JSP" New topic

Generic Table Maintenance Using Servlets & JSP

Bruno Collins

Joined: Nov 30, 2001
Posts: 19
Every system needs this but I just can't find a good example. I want to be able to maintain a table with the following or similar screen flow. (Let's take a Customer table as the example.) Step:1) Present a list of Customers (Id, Name, Suburb) with a link to View Edit or Delete. At the bottom of the list there would be an Add button. Step:2) When a link is clicked for a Customer, a second screen is displayed based upon the link. i.e. View - show all customer fields (no data entry allowed). Edit - show existing fields & values and allow editing. Delete - show all fields (protected) with an Are you sure Y/N dialogue. Add - initialise field with default values and allow entry. There would be a button to Cancel and one to Process. The Cancel button would go back to the List (1) and the Process button would validate the fields and redisplay (2) with appropriate messages should there be errors. Step:3) When there were no errors and the mode is Add/Edit/Delete the table would be updated accordingly and a final screen displayed confirming all was OK. For a View just go back to the list.
My approach (MVC) is: 1 servlet CustomerMaint which does all the flow control & database access. It would use 2 beans one to hold the list of Customers and a second to hold the details of the chosen customer. The servlet would forward to three jsp pages a) CustomerList b) CustomerMaint c) UpdateOk.
I am open to suggestions & recommendations.
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
Originally posted by Bruno Collins:
My approach (MVC) is: 1 servlet CustomerMaint which does all the flow control & database access.

My only suggestion would be to create another class which performs all of your database access. Try to isolate all calls to an external data source. That way, if you ever need to change your data source, you only have one place to do it and all of the code there is dedicated to just that. This can be an awfully nice addition for easier maintenance.
The class doesn't have to be fancy, but it should take nor pass anything back that is database specific. For example, it shouldn't do this:

As this would still require your servlet to know about JDBC classes (or interfaces), such as ResultSet and Statement. Rather, it should do something like this:

This way, the servlet is oblivious to where the customer information is coming from. It only knows that, if it provides the customer ID, it'll get back the details in a CustomerDetails object.
As far as I'm concerned, any time you're communicating with an external system, you'll want to try to encapsulate that communication and make it as loosly coupled with the rest of the system as possible.
I hope that helps,

SCJP Tipline, etc.
Dennis Farr

Joined: Mar 26, 2002
Posts: 2
I think you have a great idea there. My background is decidedly more DBA than Java at this point. I gather this tool would be for the DBA to use. It might be fun to take advantage of the system tables in the database to allow you to maintain ALL the tables with a single piece of code.
I know Sybase best. In Sybase, the idea would be to allow your tool to pick a database from sysdatabases, pick a table from systables, and then generate a form with the columns for the table by getting the syscolumns data and using it to build the form. Since you the DBA are the only one authorized to use the tool, you have no worries about someone else damaging the database with such a powerful tool.
The work would be only slightly more than coding up an application that works for just one table, and it would work for all tables nad not need to be changed if you modified the schema. Talk about reusability!
I agree. Here's the link:
subject: Generic Table Maintenance Using Servlets & JSP