webwork-user

[Webwork-user] Extending something other than ActionSupport

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

Hi -

 Rickard has mentioned before that a form bean could extend a data class
rather than ActionSupport.  How would this work in practice?  Do I need
to manually implement all the stuff from ActionSupport or
ActionFormSupport in the bean?  Am I going to run into polymorphism
problems because I'm not extending ActionSupport?

Thanks,

Tim

Re: [Webwork-user] Extending something other than ActionSupport

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

Tim White wrote:
>  Rickard has mentioned before that a form bean could extend a data class
> rather than ActionSupport.  How would this work in practice?  Do I need
> to manually implement all the stuff from ActionSupport or
> ActionFormSupport in the bean?  Am I going to run into polymorphism
> problems because I'm not extending ActionSupport?

Well, there are two ways (at least). If your data class is being written
explicitly to be used within WebWork, then you can let it subclass
ActionSupport, or ActionFormSupport (if you want the cooler error
message handling). 

However, I just stumbled into this problem myself since I had a data
object from EJB which should not have to deal with WebWork. 

To accomodate this I have now changed the *Support classes to be
concrete (i.e. not "abstract"). This allows them to be used through
delegation instead of subclassing. I.e. you can have your form bean
subclass the data bean, and also instantiate an ActionSupport class
which it can delegate to at appropriate times (e.g. execute would call
"as.getResult()" instead of "getResult()"). 

Is this sufficient? The above fixes has been added to CVS, but are not
yet available as a file release.

/Rickard

-- 
Rickard Öberg

Email: ri...@jb...

Re: [Webwork-user] Extending something other than ActionSupport

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

Rickard =D6berg wrote:
>=20
> Note that ActionSupport.getResult() uses getView("result",action). So,
> if you use getResult through delegation you should first call
> setAction(actionName) on the support class. Or, you can do
> getView("result","myaction") directly.

Would it be a good idea/helpful to include a static
getResult("myAction") method in ActionSupport and ActionForm support?=20
That way if all you are using out of there you don't even need your own
ActionSupport object...?  Or, is there a way to enhance
ActionFormSupport to look back at the calling object for the ActionName?

Thanks,

Tim

Re: [Webwork-user] Extending something other than ActionSupport

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

Hi!

Tim White wrote:
> > Note that ActionSupport.getResult() uses getView("result",action). So=
,
> > if you use getResult through delegation you should first call
> > setAction(actionName) on the support class. Or, you can do
> > getView("result","myaction") directly.
>=20
> Would it be a good idea/helpful to include a static
> getResult("myAction") method in ActionSupport and ActionForm support?

It would be possible, but I prefer to avoid statics as much as possible
(I know there are some already, but I don't really like it). If statics
are introduced there should be a really really good reason for it.

> That way if all you are using out of there you don't even need your own
> ActionSupport object...?  Or, is there a way to enhance
> ActionFormSupport to look back at the calling object for the ActionName=
?

ActionSupport (and thus ActionFormSupport) already get their action
names through the "setAction" method. If you don't want to subclass
*Support classes you can add "setAction(String)" yourself. The
Dispatcher will treat this as a request for the action name to be
passed.

regards,
  Rickard

--=20
Rickard =D6berg

Email: ri...@jb...