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