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

[Rod J. <rod...@in...>]

I think it's important that we get out the message that, although Spring
does have a good MVC framework itself, it isn't a monolithic solution. From
what I've seen of it, WW is an elegant framework (unlike certain others in
its space) and, as with Hibernate, we should make it easy for users to
combine Spring and WW. Hopefully both we and the WW community can help to
support such users.

Same goes for Tapestry.

Of course Struts integration is also going to continue to come up, and it's
good that there's another project out there focusing on it. Although we
should encourage Struts users to look at Spring MVC.

We probably need a "Using Spring with Struts" article or tutorial, as
numerous people have asked.

Regards,
Rod

----- Original Message ----- 
From: "Cameron Braid" <ca...@da...>
To: <spr...@li...>
Sent: Wednesday, November 12, 2003 3:51 PM
Subject: Re: [Springframework-developer] Re: WebWork2 integration (was:
About MVC)


> This sounds fantastic.  I am really keen to see this in action.
>
> Any idea of when it may be availible ?  If it is likely to be more than a
week, and if you have the time, could you send me a patchfile against xwork
head, and I'll apply it to a snapshot here.
>
> Thanks.
>
> Cameron
>
> Mike Cannon-Brookes wrote:
>
> The <ref>/ReferenceResolver idea should be easy to add to XWork, after
all.
> XWork already has reflection-based setting of <param> parameters; <ref>
> references could use the very same mechanism. A
> SpringServletContextReferenceResolver for WebWork2 could fetch the
> ServletContext from a ThreadLocal, grab the root WebApplicationContext
from
> the ServletContext, and resolve the reference name as bean name. A non-web
> SpringClassPathReferenceResolver could access a pre-loaded
> ClassPathXmlApplicationContext from a ThreadLocal, and resolve the
reference
> name as bean name there.
>     Wow - I should read the whole thread before replying :)
>
> As said, Ross has finished this now - we're just testing and integrating
> into the application before committing it back to XWork.
>
> At the moment it works as follows (please correct me if I've got anything
> wrong Ross).
>
> There is an ExternalEntityResolver defined on a per package level, so that
> you can have different resolvers for different packages (if needed). These
> are hierarchically looked up too, so if you specify one for the default
> package, it will filter down to all other packages.
>
> Each action can then specify external references to be resolved, as
follows:
>
> <package name="admin" namespace="/admin" extends="default"
>   external-ref-resolver="com.foo.SpringExternalReferenceResolver">
>   <action name="update" class="com.Foo">
>     <external-ref name="pageManager">myPageManager</external-ref>
>   </action>
>
> There is then a single XWork interceptor for all resolver implementations
>
(com.opensymphony.xwork.interceptors.ExternalReferenceResolutionInterceptor?
> ). This hands off to the resolver implementation to actually do the
> resolution (ie look up "myPageManager" from the Spring context, and then
set
> it using setPageManager(object) on the action instance).
>
> I believe there were a few modifications to the XWork core needed to make
it
> work nicely (such as being able to retrieve a PackageConfig from an
> ActionConfig to lookup the resolver), but it all hangs together very
nicely.
>
> The benefit of resolution being in an interceptor, like all the Xwork
> interceptors, is that you can then as the developer control the order in
> which your action is setup (ie external references, XWork IoC components,
> static parameters, web parameters etc).
>
>   I would be delighted to see that approach being adopted in
XWork/WebWork2, as
> it would allow for a really nice and straightforward combination. In terms
of
> timing, it would be good to settle that before both Spring 1.0 final (end
of
> December) and WebWork2 final (any timeframe there?). I'm happy to help on
the
> Spring side of things, but I guess we won't need any changes in Spring to
> allow for that kind of reference support in XWork.
>
> The only thing I think we decided that would be handy from the Spring side
> (that doesn't exist) is the ability to autoconfigure an existing object?
>
> 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="" in the external reference (at the cost of a little speed I
suppose)
> - but useful for lots of resolutions.
>
> Hope it makes sense.
>
> Cheers,
> Mike
>
>   Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf Of
> Cameron Braid
> Sent: Wednesday, November 12, 2003 12:36 PM
> To: spr...@li...
> Subject: [[W3-SPAM]] - Re: [Springframework-developer] Re: WebWork2
> integration (was: About MVC) - Email found in subject
>
>
> jürgen höller [werk3AT] wrote:
>
> Hi Lars,
>
> Cameron Braid has been working on XWork/WebWork2 integration and obviously
> been pleased with it (you can search our mailing list archives for the
whole
> thread).
>
> <quote>
> The bean/@id attribute relaxing is fantastic thanks!
>
> I can now use the Spring Framework as an Action Factory for
> Xwork/WebWork with no duplcation of configuration, using spring to
> define business related interceptors : components, transactions,
> security and webwork to provide web/view oriented interceptors :
> request-params, validation
>
> xwork.xml snippet :
>
> <package name="admin" namespace="/admin" extends="default">
> <action name="update" class="com.project.AdminUpdateAction"
method="txUpdate">
>   <result name="redirect">read.action?id=${id}</result>
> </action>
> </package>
>
> applicationContext.xml snippet :
>
> <bean name="/admin/update"
> class="com.datacodex.spring.webwork.WebworkActionFactoryBean">
> <property name="sessionFactory">
>   <ref local="sessionFactory"/>
> </property>
> <property name="transactionManager">
>   <ref local="transactionManager"/>
> </property>
> <property name="transactionAttributes">
>   <ref local="defaultActionTransactionAttributes"/>
> </property>
> </bean>
>
> very simple, neat and clean !
>
> Thanks guys for your fantastic framework.
>
> Cameron.
> </quote>
>
> I don't know how his integration approach works in detail but it looks
> promising. Cameron, can you give any in-depth insights? I assume the
> WebworkActionFactoryBean creates the action, being given the class name
from
> the XWork definition? How does XWork know that it needs to delegate to the
> corresponding WebWorkActionFactoryBean - I guess via some custom XWork
action
> factory? How does that action factory look up the Spring application
context?
>
>
> I have made a few posts on the webwork mailing list.
>
> See
>
http://www.mail-archive.com/ope...@li.../msg0591
> 9.html to start the thread - since then I have attempted to implement some
of
> these ideas.
>
> A basic summary :
>
> I extended the WebWork ServletDispatcher, writing a new
> SpringServletDispatcher, it makes a call to the static
> ActionProxyFactory.setFactory(new
> SpringActionProxyFactory()).
>
> SpringActionProxyFactory extends the DefaultActionProxyFactory which
overrides
> createActionInvocation to use
> a SpringActionInvocation
>
> SpringActionInvocation extends DefaultActionInvocation which overrides
> createAction to delegate to
>
WebApplicationContextUtils.getWebApplicationContext(servletContext).getBean(
be
> anName)
> to use the factory within spring to contruct this action.
>
> The servletContext is obtained using a webwork static helper that
retrieves it
> from the action context (threadlocal)
>
> This level of integration is only required if you want to use spring as
the
> action factory.
>
> Most often you will only want to use spring to provide the components that
the
> actions use, which I think is a better soloution.
>
>
> As an alternative, I still see value in extending XWork's XML action
> definition format with a <ref> tag, in addition to the existing <param>
tag.
> Those ref tags could then get resolved via a ReferenceResolver interface,
> possibly with a SpringReferenceResolver implementation that looks up the
> reference names in an application context. I've suggested that a while
ago,
> but I don't think that anyone has adopted the idea yet, as it involves an
> extension of the XWork core.
>
>
> I really like your idea of supporting an external ref type tag as core in
> xwork/webwork since it offers the simplest, and most elegent soloution.
>
> <action name="listAccounts" class="project.controller.ListAccounts">
>  ...
>   <ref name="accountsDao">accountsDao</ref>
>  ...
> </action>
> Using one of these later ideas means that the action and refrences are
totally
> defined in the webwork configuration, and components are defined in
spring,
> which is a good separation in my mind.
>
> When using spring as the action facory I was starting to find it difficult
to
> see what was going on in regards to the actions since some configuration
was
> done in xwork.xml and some in the spring context.
>
> I can have a go at adding <ref> support to the xwork configuration code -
in
> my snadbox.  In the meantime we can discuss further and see what the other
> webwork developers think.
>
> Before reading about this idea, I implemented a simple prototype (not
> production ready) system to get components from spring using a webwork
> interceptor.
>
> What happens here is you configure the interceptor in the xwork.xml file
just
> like any other webwork interceptor, using parameter to provide a mapping
of
> action proeprty to spring bean name.
>
> see
>
http://www.mail-archive.com/ope...@li.../msg0595
> 7.html
>
> A basic summary :
>
> <action name="listAccounts" class="project.controller.ListAccounts">
>  ...
>   <interceptor-ref name="springComponent">
>      <param name="mapping">
>           accountsDao=accountsDao
>      </param>
>  </interceptor-ref>
>  ...
> </action>
> this example reflectively invokes
>
action.setAccountsDao(WebApplicationContextUtils.getWebApplicationContext(se
rv
> letContext).getBean(beanName))
> obtaining the servlet context from the action context.
>
> I would prefer to use the <ref> tag since it is a lot more meaningful, and
> allows for plugable RefrenceResolvers .
>
> Thanks,
>
> Cameron
>
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Lars Fischer
> Sent: Wednesday, November 12, 2003 11:32 AM
> To: spr...@li...
> Subject: [[W3-SPAM]] - RE: [Springframework-developer] About MVC - Email
> found in subject
>
>
> I think it would be a good idea to put a focus on WebWork 2 integration.
> WebWork is a very popular framework and I think Spring would gain
> further popularity when providing a way to integrate WebWork "out of the
> box".
>
> IMO the main advantage of WebWork is that it's very easy to understand
even
> with missing documentation. Spring MVC maybe technically superior
> (I don't know) but it's too complicated to get started with.
>
> The combination of Spring as Container and WebWork 2 as MVC framework
> is very powerful.
>
> What do you think about this ?
>
> Regards,
> Lars
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -- 
> Any damn fool can write code that a computer can understand...
> The trick is to write code that humans can understand.
> [Martin Fowler
http://www.martinfowler.com/distributedComputing/refactoring.pdf]------------------------------------------------------- 
This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas.
Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java,
MySQL, WebDAV, and more! http://www.apachecon.com/
_______________________________________________ Springframework-developer
mailing list Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer