Menu
▾
▴
Re: [Springframework-developer] Re: WebWork2 integration (was: About MVC)
|
From: Cameron B. <ca...@da...> - 2003-11-12 15:55:12
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
This sounds fantastic. I am really keen to see this in action.<br>
<br>
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.<br>
<br>
Thanks.<br>
<br>
Cameron<br>
<br>
Mike Cannon-Brookes wrote:<br>
<blockquote type="cite" cite="midBBD87A92.3A318%25...@at...">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->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).
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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
</pre>
<blockquote type="cite">
<pre wrap="">Juergen
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:spr...@li...">spr...@li...</a>
[<a class="moz-txt-link-freetext" href="mailto:spr...@li...">mailto:spr...@li...</a>]On Behalf Of
Cameron Braid
Sent: Wednesday, November 12, 2003 12:36 PM
To: <a class="moz-txt-link-abbreviated" href="mailto:spr...@li...">spr...@li...</a>
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
<a class="moz-txt-link-freetext" href="http://www.mail-archive.com/ope...@li.../msg0591">http://www.mail-archive.com/ope...@li.../msg0591</a>
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
<a class="moz-txt-link-freetext" href="http://www.mail-archive.com/ope...@li.../msg0595">http://www.mail-archive.com/ope...@li.../msg0595</a>
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(serv
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: <a class="moz-txt-link-abbreviated" href="mailto:spr...@li...">spr...@li...</a>
[<a class="moz-txt-link-freetext" href="mailto:spr...@li...">mailto:spr...@li...</a>]On Behalf
Of Lars Fischer
Sent: Wednesday, November 12, 2003 11:32 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:spr...@li...">spr...@li...</a>
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! <a class="moz-txt-link-freetext" href="http://www.apachecon.com/">http://www.apachecon.com/</a>
_______________________________________________
Springframework-developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Spr...@li...">Spr...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/springframework-developer">https://lists.sourceforge.net/lists/listinfo/springframework-developer</a>
</pre>
</blockquote>
<pre wrap=""><!---->
-------------------------------------------------------
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! <a class="moz-txt-link-freetext" href="http://www.apachecon.com/">http://www.apachecon.com/</a>
_______________________________________________
Springframework-developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Spr...@li...">Spr...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/springframework-developer">https://lists.sourceforge.net/lists/listinfo/springframework-developer</a>
</pre>
</blockquote>
<br>
<br>
<pre cols="72" class="moz-signature">--
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler <a class="moz-txt-link-freetext" href="http://www.martinfowler.com/distributedComputing/refactoring.pdf">http://www.martinfowler.com/distributedComputing/refactoring.pdf</a>]</pre>
</body>
</html>
|
