I haven't played with it yet... but what about the new validation stuff? Could you maybe set up a validator such that any call to an illegal setter is rejected as invalid input?
----- Original Message ----- From: "Jason Carreira" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 17, 2003 9:39 PM Subject: RE: [OS-webwork] formbean vs. action > It depends... If you use the TokenTag and use different token names from > form to form then it will only be a problem if you have two windows open > to the same form. If you saved the parameter names per form name > (instead of using tokens) it wouldn't be a problem. > > I would say, though, that if you're concerned about this type of thing, > you could just put only the properties you want to be settable on the > Action itself and build/edit/save your domain objects in the execute() > (or whatever) method... > > > -----Original Message----- > > From: Tim Dwelle [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, September 17, 2003 9:22 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [OS-webwork] formbean vs. action > > > > > > But wouldn't this technique break if you have 2 browser windows open? > > > > > > > > ----- Original Message ----- > > From: "Cameron Braid" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Wednesday, September 17, 2003 7:48 PM > > Subject: RE: [OS-webwork] formbean vs. action > > > > > > > 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. > > > > > > > > > If someone adds invoice.balance=0 to the http request, it > > will also be > > > automatically set onto the domain object. > > > > > > > > > I have a technique that can avoid this, for actions that > > are using the > > > JSP tag library to produce the forms. > > > > > > It goes something like this : > > > > > > A) in the taglibs, keep a list of the property names of each form > > > field > > > B) store this list in the session, against the form token > > for retrival > > > on post > > > C) when the form is posted, obtain this list of form fields > > > D) the params interceptor only sets the properties defined > > in this list > > > > > > This allows the form to define allowable properties to set on the > > > target action, therby 'protecting' unwanted request params from > > > affecting anything. > > > > > > > > > > > > Cameron > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > > On Behalf Of > > > Jason Carreira > > > Sent: Wednesday, 17 September 2003 10:40 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [OS-webwork] formbean vs. action > > > > > > > > > The fact that it's not a class built specifically for backing this > > > form... Struts requires you to build form beans which extend an > > > abstract base class. Here you're just using your same > > domain objects > > > directly, without a mapping layer. > > > > > > > -----Original Message----- > > > > From: Anoop Ranganath [mailto:[EMAIL PROTECTED] > > > > Sent: Wednesday, September 17, 2003 8:29 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: [OS-webwork] formbean vs. action > > > > > > > > > > > > > If you're using domain objects or persisting the data, I > > > > would suggest > > > > > you use Object properties. Say, for instance, that you have > > > > an Invoice > > > > > domain object. You might have an CreateInvoiceAction > > Action class: > > > > > > > > Ah. That's actually what I'm doing right now. So what > > makes this > > > > any different than a Form Bean then? The fact that it's a POJO? > > > > > > > > Anoop > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > 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 > > > > > > > > > > > > > ------------------------------------------------------- > > > 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 > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > 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 > > > > > > ------------------------------------------------------- > > 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 > > > > > ------------------------------------------------------- > 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 ------------------------------------------------------- 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
