This is an issue with the typical edit/save scenario. The problem we are discussing is that the domain model is needed in some form before the parameter can be repopulated from the form save. The technique you are using is to reread the data from the database before the parameters are set. An alternative technique would be to put the domain model into a place in the session--so on the save, you can retrieve the the model from the session and then allow the parameters interceptor to populate the new data. (This is referred to as detached objects in the Hibernate world) The advantage of putting the model in the session is that if some else modifies the data before you reread the data, but after you have displayed the edit page, you will not have the original model. This particularly a problem with a model where you are dealing with lists of domain objects. In this case, the edit will fail because you will be trying to set parameters on items that might not exist anymore. (Or you've pulled in data that the user doesn't know about) Therefore the safer technique is to save off the model. If you're concerned about putting too much into the session, you can store the data in a cache, such as ehcache, that will store items to disk if there are too many things in memory. (This is the technique that we used--we called it a model repository and we created a couple different implementations) I would love to see something like this out-of-the-box with struts2, but nothing currently exists. Tom
On 1/25/07, Célio Cidral Junior <[EMAIL PROTECTED]> wrote:
2007/1/25, Dave Newton <[EMAIL PROTECTED]>: > From my point of view it seems like your implementation is broken: if you need to create a Customer from an ID passed via a form or URL then you either need to implement Preparable or do the DAO operations in the (in your case) input or save methods. The DAO operations already do that. The problem happens when the user is *altering* an existing customer (creating a new customer works fine), more specifically when the user is submitting changes from the form to an existing customer object (alongside with an existing id); in that case, the id must be set before getCustomer() is called, otherwise a new customer will be created with zero id. Loading the form with an existing customer works fine. Submitting changes to it is where the problem resides. The idea behind getCustomer() is to abstract the retrieving of the customer object wherever it's called along the action's code so that I don't have to care about whether it's an existing customer or not. Implementing Preparable does not seem to solve the problem because the parameters are set before the prepare() method is invoked. Célio. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
