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.
Joined: Dec 20, 2001
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, Corey
Bruno, 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!