Unfortunately I don't think that's possible. The parameters get put into a map structure, so the original parameter order is lost by the time it gets to the servlet API. We've run into several instances where something will work on one app server, but break on another because we had duplicate parameters on the url--so depending on how the app server handled it, we would get one or the other value. I can't imagine that any java web framework could do this successfully. Tom
On 1/25/07, Célio Cidral Junior <[EMAIL PROTECTED]> wrote:
2007/1/25, Tom Schneider <[EMAIL PROTECTED]>: > 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. Thanks, I really appreciate your suggestions. However, I prefer a stateless approach because (I think) it helps to keep things simple in this case. Using some kind of cache between page requests is more like a stateful approach that I would like to avoid here for simplicity reasons. Well, having Struts passing parameters in the order defined by the html form would solve my problem. :-) Regards, Célio. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
