Re: [Webwork-user] Setting Property of a Property

[Rickard <ri...@te...>]

Hi!

Tim White wrote:
> Right, and of course I do need to both Person and Account, and some
> others. :)

Bugger...

> Hmmm.  Some of the entity beans have quite a few fields, and I'm still
> worried about having yet another set of getters and setters in a another
> object for the same data.  One thing to note, based on some fooling
> around I was doing, you can only pass in String parameters as far as I
> can tell to be automatically set.  This prevents you from using a Data
> class where some items are Integers etc.

This is incorrect. PropertyEditors are used. PropertyEditors for all
primitive types are available by default, and you can install your own
or create BeanInfo objects to have more control (I prefer BeanInfo
objects, especially since I generate them with a custom doclet..).

> There has to be some way of leveraging existing objects for this - this
> is Java after all. :)

Indeed, and fear not, it is there :-) Try making a setFoo(int x) method.
Also look in the dispatcher code (setParameters) for details.

> Here are some thoughts:
> 
> What are you doing with "extra" parameters passed in on the form submit
> right now?  Are they being discarded?  

yes, due to the "action pulls what it needs" philosophy. If you want to
use more of the parameters, simply define more setX() methods.

> If so, perhaps they could instead
> be placed in a collection that lived in ActionSupport.  A method of that
> collection could map it's contents to the getters and setters of a
> target object in the subclass, hopefully doing String-to-datatype
> conversions if needed.

Well, you can always bypass this whole servlet-agnostic thing and
implement ServletAware. This will give you the servlet request, from
which you can get the parameters.

> Or, if the extra parameters are still living in the ServletContext, you
> could provide a method in ActionSupport to pull them out and assign them
> to an object within the form bean.

As above, this is already available :-) Either implement ServletAware,
or subclass ServletAwareActionSupport. This "backdoor" ensures that one
can always get the whole shebang if necessary, although I prefer the
servlet-agnostic Action-style as much as possible (keeps them clean and
simple, and also makes it possible to reuse in Swing UI, and makes it
easier to do automatic testing outside of servlet environment!).

regards,
  Rickard

-- 
Rickard Öberg

Email: ri...@te...
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com