The documentation for the ParametersInterceptor [1] mentions the ParameterNameAware interface [2]. Maybe that could be a solution?
Nils-H [1] - http://struts.apache.org/2.1.6/docs/parameters-interceptor.html [2] - http://struts.apache.org/2.1.6/struts2-core/apidocs/com/opensymphony/xwork2/interceptor/ParameterNameAware.html On Mon, Mar 23, 2009 at 1:53 PM, José Santos <santos.sw...@gmail.com> wrote: > hi, > > what's the recommended design for avoiding fields of DTOs in the value stack > being updated through (HTML) DOM manipulation? > > consider a typical edit page containing a form with some fields. this page > is a visual representation of a DTO we are about to update. the DTO is set > in the action - it was fetched from the database during prepare() - and > therefore is accessible from the value stack (the JSP generating the edit > page populated the form fields with corresponding DTO fields using OGNL). > > by manipulating the DOM of the edit page (e.g. using Firebug) one can add a > new input field to the form. this input field may correspond to a DTO > read-only instance variable we would like the action *not* to update. upon > form submission, the DTO is updated with all the form fields (existing ones > + the one added to the DOM) and persisted in the database. > > there are several possible solutions to this issue: > > solution 1: validate the DTO before persisting it in the database. the DTO > would be persisted only if no "read-only" fields were updated. this could be > achieved e.g. through a comparison between the updated DTO and a clone of > the original DTO (fetched during prepare()). > > solution 2: another way to solve this would be to apply authorisation rules > in the model and therefore guarantee that certain DTO setters are > "read-only". > > solution 3: use a DTO proxy object instead of the DTO itself. the DTO proxy > object would contain the DTO read-write fields only. the DTO would then be > updated with the corresponding DTO proxy fields before being persisted in > the database. > > solution 4: not to use the "model-driven" approach and have setters in the > action corresponding to DTO read-write fields. the DTO would then be updated > with the corresponding action fields before being persisted in the database. > > i am not considering a solution where setters of "read-only" fields are > removed from the DTO class as this would invalidate the update of those > fields by anyone (which includes users with higher privileges). > > i would like to hear about your design solutions to this issue. > > thanks in advance, > santos. > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
