Re: [Springframework-developer] Re: WebWork2 integration (was:About MVC)

[<jue...@we...>]

> <package name=3D"admin" namespace=3D"/admin" extends=3D"default"
>  external-ref-resolver=3D"com.foo.SpringExternalReferenceResolver">
>   <action name=3D"update" class=3D"com.Foo">
>     <external-ref name=3D"pageManager">myPageManager</external-ref>
>   </action>
>=20
> This would consist of giving an object and a series of names (or other
> objects?) to the context, and it then working out how they are best
> autowired together. This would mean you wouldn't necessarily need the
> name=3D"" in the external reference (at the cost of a little speed I =
suppose)
> - but useful for lots of resolutions.

I guess you mean it wouldn't necessarily need the *body* of the =
external-ref tag? The "name" is supposed to be the name of the action =
property, i.e. referring to the "setPageManager" setter, isn't it?

To support resolving by type too, the ExternalReferenceResolver =
interface's "resolveReference" method would need to pass in the required =
type in addition to the name, i.e. both PageManager.class (as retrieved =
by introspection of the action property "pageManager") as type and =
"myPageManager" as name:

public interface ExternalReferenceResolver {
  Object resolveReference(Class requiredType, String name);
}

The SpringXxxReferenceResolver implementation could then call =
getBean(name, requiredType) on the application context if the name is =
given - this method already exists as overloaded alternative to =
getBean(name).

If the name is null, i.e. the body of the <external-ref> tag was empty, =
the Spring resolver implementation could call =
BeanFactoryUtils.beanOfTypeIncludingAncestors(applicationContext, =
requiredType, true, true) which returns a single object or throws an =
exception. A similar BeanFactoryUtils.beansOfTypeIncludingAncestors =
method exists already in 1.0 M2; beanOfTypeIncludingAncestors is a new =
convenience method that will be released in the upcoming 1.0 M3 next =
week.

You could even try to add autowiring functionality, e.g. via an =
"external-ref-autowire=3Dtrue/false" setting. If autowiring is =
activated, the resolver interceptor could iterate over all the action's =
non-simple (non-primitive and non-String) properties that haven't =
explicit <external-ref> tags, and invoke resolveReference for each type. =
We have a similar mechanism for Spring bean factories: It works nicely =
if you've just got one single bean per type and no optional =
dependencies.

Juergen