One problem that comes to mind with this approach is that if someone 'hacks' the request, specifying parameters that aren't meant to be coming in.
i.e - using your example
Public class CreateInvoiceAction extends ActionSupport { private Invoice invoice = new Invoice();
... } <input type="text" name="invoice.poNum" value="${invoice.poNum}"/> Calls getInvoice().setPoNum() to set the value.
True enough. Being able to use your domain objects directly means that you end up having a lot more flexibility with your inputs with less code. Unfortunately, it does mean that you do have to guard against cases like what you're describing.
I think a good practice is to have the domain objects do the work of selectively updating fields. So if I have the following action:
public class UpdateMyAccount implements Action {
private AccountManager accountManager;
private Account account = new Account();public Account getAccount() { return this.account; }
...
public void execute() {
this.accountManager.update(account);
}
}the update method of accountManager will know which fields within account should be updated. I found this approach also made unit testing easier.
Another method which might also work, but is a little more heavy handed is to write a custom TypeConverter for fields you want to mark as hidden. For example, if I balance is reserved for internal use only, I could write a Type converted that threw away and user data that attempted to set balance.
M
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
