Menu
▾
▴
Re: [Springframework-developer] Re: WebWork2 integration (was:About MVC)
|
From: <jue...@we...> - 2003-11-12 13:02:15
|
Hi Mike, I'm *DELIGHTED* to hear that! :-) I didn't know that you respectively = Ross had already picked up my idea...=20 Regarding the naming and implementation of such reference resolvers, I'd = like to re-suggest what I wrote to Cameron a few minutes ago: A Spring = reference resolver that accesses the root web application context via = the ServletContext should probably be called = "SpringServletContextReferenceResolver" or the like, while a non-web = Spring reference resolver could be called = "SpringClassPathReferenceResolver", using Spring's = ClassPathXmlApplicationContext. I guess the main focus is on web = applications anyway, so this is just meant as minor hint towards non-web = usage. <self-quote> 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. </self-quote> BTW, can you comment on the timeframe for a WebWork2 final release or at = least an RC? As I've already mentioned before, we're targeting beginning = of December for Spring 1.0 RC1 and end of December for 1.0 final. It = would be nice to have that kind of Spring/WebWork integration already = available by then, with proper releases of both frameworks. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Mike Cannon-Brookes Sent: Wednesday, November 12, 2003 1:49 PM To: Spring Developer Subject: [[W3-SPAM]] - Re: [Springframework-developer] Re: WebWork2 integration (was:About MVC) - Email found in subject > 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 >=20 > -----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 >=20 >=20 > 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". >=20 > 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. >=20 > The combination of Spring as Container and WebWork 2 as MVC framework > is very powerful. >=20 > What do you think about this ? >=20 > Regards, > Lars >=20 >>> 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) >>=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 >=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 >=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 ------------------------------------------------------- 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 |
