|
From: <jue...@we...> - 2003-11-12 11:05:51
|
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=20
Xwork/WebWork with no duplcation of configuration, using spring to=20
define business related interceptors : components, transactions,=20
security and webwork to provide web/view oriented interceptors :=20
request-params, validation
xwork.xml snippet :
<package name=3D"admin" namespace=3D"/admin" extends=3D"default">
<action name=3D"update" class=3D"com.project.AdminUpdateAction" =
method=3D"txUpdate">
<result name=3D"redirect">read.action?id=3D${id}</result>
</action>
</package>
applicationContext.xml snippet :
<bean name=3D"/admin/update" =
class=3D"com.datacodex.spring.webwork.WebworkActionFactoryBean">
<property name=3D"sessionFactory">
<ref local=3D"sessionFactory"/>
</property>
<property name=3D"transactionManager">
<ref local=3D"transactionManager"/>
</property>
<property name=3D"transactionAttributes">
<ref local=3D"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?
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.
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
> > Do you not think that configuring some of this peripheral=20
> > data should be at the view level? If not the view, then=20
> > where..? In common scenarios I come across, the secondary=20
> > model is quite specific to a view (though not of course the=20
> > TYPE of view)
>=20
> >From what I've seen there's three commons scenerio's
>=20
> 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)
>=20
> 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
>=20
> 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!
>=20
> 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.
>=20
> It's just some rambling, but maybe we could brainstorm about this more
> in order to come with something brilliant :)...
>=20
> Alef
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> 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
>=20
-------------------------------------------------------
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
|