Menu
▾
▴
Re: [Springframework-developer] Re: WebWork2 integration (was: About MVC)
|
From: Cameron B. <ca...@da...> - 2003-11-12 11:39:56
|
<!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">
jürgen höller [werk3AT] wrote:<br>
<blockquote type="cite"
cite="mid...@co...">
<pre wrap="">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?
</pre>
</blockquote>
I have made a few posts on the webwork mailing list.<br>
<br>
See
<a class="moz-txt-link-freetext" href="http://www.mail-archive.com/ope...@li.../msg05919.html">http://www.mail-archive.com/ope...@li.../msg05919.html</a>
to start the thread - since then I have attempted to implement some of
these ideas.<br>
<br>
<u>A basic summary :</u><br>
<br>
I extended the WebWork ServletDispatcher, writing a new
SpringServletDispatcher, it makes a call to the static
ActionProxyFactory.setFactory(new <br>
SpringActionProxyFactory()). <br>
<br>
SpringActionProxyFactory extends the DefaultActionProxyFactory which
overrides createActionInvocation to use <br>
a SpringActionInvocation<br>
<br>
SpringActionInvocation extends DefaultActionInvocation which
overrides createAction to delegate to
WebApplicationContextUtils.getWebApplicationContext(servletContext).getBean(beanName)
<br>
to use the factory within spring to contruct this action.<br>
<br>
The servletContext is obtained using a webwork static helper that
retrieves it from the action context (threadlocal)<br>
<br>
This level of integration is only required if you want to use spring as
the action factory.<br>
<br>
Most often you will only want to use spring to provide the components
that the actions use, which I think is a better soloution.<br>
<br>
<blockquote type="cite"
cite="mid...@co...">
<pre wrap="">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.
</pre>
</blockquote>
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.<br>
<pre><font face="Courier New, Courier, monospace"><action name="listAccounts" class="project.controller.ListAccounts">
...</font></pre>
<pre><font face="Courier New, Courier, monospace"> <ref name="accountsDao">accountsDao</ref></font></pre>
<pre><font face="Courier New, Courier, monospace"> ...</font></pre>
<pre><font face="Courier New, Courier, monospace"></action></font></pre>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Before reading about this idea, I implemented a simple prototype (not
production ready) system to get components from spring using a webwork
interceptor. <br>
<br>
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.<br>
<br>
see
<a class="moz-txt-link-freetext" href="http://www.mail-archive.com/ope...@li.../msg05957.html">http://www.mail-archive.com/ope...@li.../msg05957.html</a><br>
<br>
<u>A basic summary :</u><br>
<pre>
<font face="Courier New, Courier, monospace"><action name="listAccounts" class="project.controller.ListAccounts">
...</font></pre>
<pre><font face="Courier New, Courier, monospace"> <interceptor-ref name="springComponent"></font></pre>
<pre><font face="Courier New, Courier, monospace"> <param name="mapping"></font></pre>
<pre><font face="Courier New, Courier, monospace"> accountsDao=accountsDao</font></pre>
<pre><font face="Courier New, Courier, monospace"> </param></font></pre>
<pre><font face="Courier New, Courier, monospace"> </interceptor-ref></font></pre>
<pre><font face="Courier New, Courier, monospace"> ...</font></pre>
<pre><font face="Courier New, Courier, monospace"></action></font></pre>
this example reflectively invokes
action.setAccountsDao(WebApplicationContextUtils.getWebApplicationContext(servletContext).getBean(beanName))<br>
obtaining the servlet context from the action context.<br>
<br>
I would prefer to use the <ref> tag since it is a lot more
meaningful, and allows for plugable RefrenceResolvers .<br>
<br>
Thanks,<br>
<br>
Cameron<br>
<br>
<blockquote type="cite"
cite="mid...@co...">
<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 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
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Do you not think that configuring some of this peripheral
data should be at the view level? If not the view, then
where..? In common scenarios I come across, the secondary
model is quite specific to a view (though not of course the
TYPE of view)
</pre>
</blockquote>
<pre wrap="">>From what I've seen there's three commons scenerio's
1. Reference data needed to render the view. This is the stuff we have
already.
2. Data related to the view but not necessarily needed to render it
(additional news in a sidebox, perhaps a menu).
3. Componentized views having corresponding controller (portlet)
The first case can perfectly be implemented using our current reference
data implementation (a list of elements in a select box of a form for
instance). One controller, having reference data, specifically belonging
to the controller
The second case (sideboxes containing news, a menu that needs
information not related to the main view) I consider to be a simple
Tiles approach and I think a somewhat more advanced version of the
reference data features we have now, would do. Something like you
proposed maybe. Reference data, however, not in fact related to the
controller!
The third case however, is a completely different one and somewhat looks
like the portlet approach. I think this is a bit too far-fetched to
implement in Spring, although I'd like to offer view-tech independent
stuff for this. Parallel controllers rendering views independent of
eachother.
It's just some rambling, but maybe we could brainstorm about this more
in order to come with something brilliant :)...
Alef
-------------------------------------------------------
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>
-------------------------------------------------------
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>
|
