i tried solution 4 where the action: - has the DTO itself as an instance variable (as opposed to having DTO fields as instance variables) - implements ParameterNameAware
it works ok with regard to parameter interception but the parameters are not checked by validation annotations. this is because these parameters are set in the DTO itself not in the action. so I have just implemented solution 4 as you suggested i.e. having parameters in the form corresponding to action variables: - the prepare() method gets the DTO and sets it in a private instance variable (no DTO getter/setter) - the save() method updates the private DTO with the read-writable parameters set in the action this way, the DTO is set with corresponding action variables which are guaranteed to be: - read-writeable: they belong to the white list of allowed parameters used by acceptableParameterName() (interface ParameterNameAware) - valid: they are checked by validation annotations however, with this set up (parameters as instance variables instead of DTO as instance variable) the acceptableParameterName() is no longer needed, because the only setters available in the action are the ones corresponding to read-writeable parameters. i will leave actions implementing ParameterNameAware anyway. it's an extra protection which may be helpful in cases where additional setters (either in the action or in action subclasses) are added and one wants explicit control over allowed parameters. thanks again, santos. On Mon, Mar 23, 2009 at 2:12 PM, Nils-Helge Garli Hegvik <[email protected]>wrote: > 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 <[email protected]> > 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: [email protected] > For additional commands, e-mail: [email protected] > >
