webwork-user

[Webwork-user] Setting Property of a Property

[Tim W. <tl...@us...>]

Well, I can get the property of a property by separating them with :,
that's very cool.

But I can't seem to set the property of a property in an action the same
way.

I'd prefer not to define getters and setters for all my data object's
fields again in the action class, since I have a lovely PersonData class
generated by EJBDoclet that already has all those getters and setters.

I'd like to make the name of an HTML Form field currentPerson:lastName
and have webwork set the lastName field of the PersonData attribute of
the PersonEdit class.

Is this possible?  I can't seem to get it to work - I have debug turned
on, and the Dispatcher doesn't appear to be recognizing the : fields in
setParameters.

Any thoughts?

Thanks,

Tim

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

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

Hi!


> But I can't seem to set the property of a property in an action the same
> way.
>
> I'd prefer not to define getters and setters for all my data object's
> fields again in the action class, since I have a lovely PersonData class
> generated by EJBDoclet that already has all those getters and setters.
>
> I'd like to make the name of an HTML Form field currentPerson:lastName
> and have webwork set the lastName field of the PersonData attribute of
> the PersonEdit class.
>
> Is this possible?  I can't seem to get it to work - I have debug turned
> on, and the Dispatcher doesn't appear to be recognizing the : fields in
> setParameters.
>
> Any thoughts?

Wow, that is a great idea! :-) Why didn't I think of that... add this to the
task tracker on the site.

Or can anyone think of semantical problems with it? Off the top of my head
it seems very cool, but I might be missing something...

regards,
  Rickard

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

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

On second thought...

> > But I can't seem to set the property of a property in an action the same
> > way.
> >
> > I'd prefer not to define getters and setters for all my data object's
> > fields again in the action class, since I have a lovely PersonData class
> > generated by EJBDoclet that already has all those getters and setters.
> >
> > I'd like to make the name of an HTML Form field currentPerson:lastName
> > and have webwork set the lastName field of the PersonData attribute of
> > the PersonEdit class.
> >
> > Is this possible?  I can't seem to get it to work - I have debug turned
> > on, and the Dispatcher doesn't appear to be recognizing the : fields in
> > setParameters.
> >
> > Any thoughts?
>
> Wow, that is a great idea! :-) Why didn't I think of that... add this to
the
> task tracker on the site.
>
> Or can anyone think of semantical problems with it? Off the top of my head
> it seems very cool, but I might be missing something...

There are problems with this. This is what we are talking about:
?foo:bar=xyzzy should result in action.getFoo().setBar("xyzzy");

The first problem is a coding one. The action dispatcher currently sets
parameters in a "pull" way: it gets the actions BeanInfo and for all setX
found it calls it with the corresponding value from parameters. I.e. we go
from action to parameter. With the : notation on parameters it would have to
be the other way round, i.e. parameters are "pushed" into the action. This
is bad because sometimes only a subset of the parameters should be set (if
actions are used in a hierarchical way), and it is also more computationally
expensive since the dispatcher would have to list the parameters and for
each parameter do a linear search of the bean properties to find the right
one. The complexity would be O(N^2) instead of O(N), which is bad.

Another problem is that it would change the semantics of how actions are
used somewhat. Currently the flow is
1) call setters
2) call execute
3) call getters
With the : notation this would change to
1) call setters, and possibly get and set on return value of get
2) call execute
3) call getters
which I'm not quite happy with.

What do you think?

There is also a workaround for what you want to do: let the action subclass
your PersonData. This is actually how most of the actions work in EBS: the
base class is a barebones JavaBean with get/set, and whose execute method
does nothing, and they are then subclassed with actions that only implement
execute and additional get methods for result data.

Is this ok for you? The only drawback with this that I can think of is if
your form include both PersonData and AccountData, because your action can't
subclass both at the same time.

/Rickard

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