Why do actions have to extend framework classes

Why do actions have to extend framework classes? One of JSF marketing features was that this was not necessary. Why is it necessary with webflow? I am just asking so if anyone asks me I will know the answer.

Action is a interface. Your actions must implement the Action interface, they don't neccessarily have to extend from a base class.

The action is a central concept in web flow--it executes some logic in the context of the current request, and returns a result. Such a concept needs a strongly typed interface definition. Relying on abritrary method binding using reflection just seems too generic here--if you need that, just use a MultiAction with a configured delegate.

Keith

Here are examples...

public class ExecuteQueryAction extends AbstractAction {

public class MyFormAction extends FormAction {

extends MultiAction..


Are these all just helper methods? If so and they are necesary why in your opinion did JSF not follow the same general guidelines.

Even multiaction has to extend why... I dodn't see how I would need it to extend anything. I would expect a method to be called and return a result.


If you could please provide a little info on

Quote:

---

"Such a concept needs a strongly typed interface definition. Relying on abritrary method binding using reflection just seems too generic here"

---

. More in light of why in JSF land it's a good idea not to extend and how they get away with not extending and why here it is not so.

Once again I am not questioning I am just trying to understand.

Not having the Action interface does not bring real benefits, and having it helps a great deal in clarifying the contract of an action and making it explicit.

Anyway, the action is just "glue code": it bridges between the SWF system and your own (business) code. So if you want the SWF system to call "normal" methods on your own objects, which are completely unrelated to SWF, just code a special Action to make that possible (or use MultiAction with a special ActionExecuteMethodNameResolver and delegate object).

So in summary, you can basically say that JSF looks at its backing beans as being part of the application code, not JSF code. SWF looks at actions as being extensions of SWF, not general purpose parts of the application code.

Eriwn

well said!

So webflow actions are similar to struts actions... Where you were not supposed to put a lot of app code there either. It was just a bridge ("glue")) to your app code. The only diff between the contract in Struts and the contract in webflow is that with struts you had to extend and with webflow it's an interface. But realistically with webflow the most likely scenario is also to extend either abstractaction or multiaction so there's not much difference at all. Am I right?

Well, they're not really similiar to Struts actions...

Struts actions are controllers - they do some stuff and select which view to go next.

Web flow actions are commands - they execute some behavior and return a result of that execution. The web flow system responds to that result and decides where to go next.

Quote:

---

Where you were not supposed to put a lot of app code there either. It was just a bridge ("glue")) to your app code. The only diff between the contract in Struts and the contract in webflow is that with struts you had to extend and with webflow it's an interface.

---

Well there actually is a pretty big difference in having the option of having your own superclass, rather than being forced to extend a framework class. In Spring generally, where you extend a framework superclass, it's an implementation convenience, rather than an absolute necessity. Implementation convenience is generally a good way of looking at concrete inheritance IMO.

Of course SWF and Struts are completely different things, so they can't be compared. But the real problem with Struts and OO is more that you can't bind onto domain objects that don't know about Struts. It's ActionForm, not Action, that is problematic. With SWF you can have relatively little code in Actions, but you can leverage the domain objects you already have.