On Tue, 11 Mar 2003 11:53:07 -0700 "Jeff Smith" <[EMAIL PROTECTED]> wrote: > > So if my data specification ever changes - suppose I add > "preferredLanguage" as a new field in my customer record - I have to > go through all my transaction methods and add the new field as a > parameter to all the appropriate business methods.
Do you mean you are passing the actual fields into methods? Why not just pass an object (data transfer object) that represents your customer into the methods? ie.... updateCustomer( CustomerDTO customer ). All you methods would stay the same if any changes occurred. There is even Object Relational Mapping stuff that I haven't looked into where you can map your objects fields to database columns. We're stuck using JDBC here and even with that, I had one time wrote a class that does use reflection and can call the right setters and getters to set PreparedStatements, or going the other way, will take ResultSet fields and populate your bean. (Only trick was you had to make sure that you named the columns for your query the same bean field names). > Then I have to go to my UserForm bean and add the necessary member > variable as well as the getters and setters to support my new field. Using the DynaActionForm stuff this is a piece of cake. Just type the name of the new field in the config.xml file. Later, then just use BeanUtils.copyProperties to copy all of your DynaActionForm beans properties to the DTO you created. > Then I have to go to the various JSPs to add this new field to the > input forms and profile display screens. Well, not sure how to help there. I'm sure you could create a generic tag if there isn't one already, that maybe strips fields out of your form bean and makes input fields, etc. To me the view at this level is so specialized there isn't much point in cutting corners with a dynamic solution. -- Rick Reumann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
