|
From: Mike Cannon-B. <mi...@at...> - 2003-11-12 12:49:46
|
> 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, This is exactly what Ross (one of our new developers) has been implementing and it looks like it will work very nicely indeed. The benefit is that you keep XWork actions in xwork.xml, Spring beans in applicationContext.xml - so you have good separation. Cheers, Mike > > -----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 >>> 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) >> >>> 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! 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 > > > ------------------------------------------------------- > 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 |