FormAction does not implement ApplicationContextAware?

[jdeeden]

Or am I missing something? It seems perfectly acceptable (and even preferable) for FormAction to implement ApplicationContextAware, yet it does not. Why?

Josh

[Keith Donald]

Why does it need to?

[jdeeden]

Why does Spring's AbstractController need to? It doesn't, but it's awfully convenient that it does. With that said, the question I should have asked was why doesn't either the Action interface or AbstractAction extend/implement the ApplicationContextAware interface?

In my apps, the main responsibility of the controller layer is to look up business delegates from the spring context, executing whatever method, and then dispatching to a view with the output. Using webflow, everytime I create a new controller, I have to explicitly tell that controller to make itself aware of its own context? Seems like unnecessary boiler-plate code to me...

Maybe I'm missing something? Is it a question of decoupling spring webflow from spring core?

[jdeeden]

Allow me to correct myself again... In addition to being ApplicationContextAware, AbstractAction should also implement the getApplicationContext() method. This would make AbstractAction behave more like AbstractController, which I would argue is a good thing...especially for people like me who are refactoring Spring Controllers into Spring Web Flow Actions.

[Keith Donald]

But why not just use dependency injection everywhere?

Basically, we've taken the stance to date that use of the AC from a webflow action is not a common case and doesn't warrant providing a reference to it in AbstractAction. If you need the AC, you could always create your own action superclass that was AC aware.

What kinds of things do you need it for and why can't you just use DI?

Keith

[jdeeden]

Dependency Injection... Oh yes, I remember hearing something about that strange little concept. Sometimes the obvious escapes me. For business delegates, DI definitely makes the most sense. But in the case where the controller needs one or more (determined at runtime) prototype bean instances from the bean factory, access to the context is necessary.

I guess the case could be made that controllers should be dumb proxies, not responsible for implementing logic which requires the instantiation of multiple prototype beans... Nonetheless, there are those times when convenient access to the context from the controller is useful, IMHO.

Perhaps the most compelling argument for making AbstractAction classes ApplicationContextAware, is that AbstractAction classes are. Simply having the get/setApplicationContext() interfaces available to FormActions makes the process of adapating from Spring MVC to WebFlow more natural, and existing code slightly more portable.

From a design perspective, I understand your rationale. From a API consumer perspective, I would find it useful.

As a sidenote, I enjoy using the framework and it's been fun learning it. Nice work.

Josh

[Keith Donald]

Not neccessarily, you can use lookup-method or inject a custom locator to return a prototype :-)

Glad u like! SWF will only get better :-)

Keith