See below: > -----Original Message----- > From: Butt, Dudley [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 24, 2003 9:59 AM > To: '[EMAIL PROTECTED]' > Subject: [OS-webwork] FW: Porting your WW1 apps to WW2 > > > > > -----Original Message----- > From: Butt, Dudley > Sent: Thursday, July 24, 2003 3:30 PM > To: '[EMAIL PROTECTED]' > Subject: Porting your WW1 apps to WW2 > > > Hi,, > > How difficult will it be to port your WW1.3 apps to WW2, > also....here's a comment I picked up from the web about > Struts and WW, read.....
There's some porting docs getting started on the wiki (wiki.opensymphony.com) > > One of the appealing things about Webwork > <http://www.opensymphony.com/webwork/> is that Webwork > actions are not tied to the web (i.e. the Servlet API) in the > way that Struts <http://jakarta.apache.org/struts/> actions > are. You can use Webwork as a generic action framework, > implement your business APIs as actions, and then re-use > those APIs behind any UI technology: web, Swing, AWT, > command-line, etc. You've probably heard WebWork advocates > tout this genericity as a major advantage of Webwork over > Struts. According to Anders Hovmoeller, writing > <http://sourceforge.net/mailarchive/forum.php?thread_id=151341 > 3&forum_id=10237> to the WebWork mailing list, it is the key > advantage of WebWork over > Struts: > Anders Hovmoeller In my opinion, the > only really solid argument for using WW over say Struts is > that we are not locked up in a certain environment. I firmly > believe that the core parts of XW can easily avoid being tied > up to servlets, as WW does now. > But this is opinion is not shared by all > WebWorkers. Rickard Oberg > <http://freeroller.net/page/rickard>, the original architect > of Webwork (who recently resigned > <http://sourceforge.net/mailarchive/forum.php?thread_id=148398 > 7&forum_id=10237> from his position as architect of the > project), does not see it that way. This is from a Jan 13, > 2003 post > <http://sourceforge.net/mailarchive/forum.php?thread_id=151341 > 6&forum_id=10237> > on the Webwork mailing list: > Rickard Oberg That WebWork turned out > to be a generic command pattern was more of an accident then > by design. Because of this genericity WebWork is not > optimally designed for doing web work. Some of the "plumbing" > needs to be done by actions themselves, instead of having it > be done by the framework. I want to make WebWork/XWork > *better* suited for the web, because that is what *I* *need*. > I want to get more for less. I don't give a damn about making > it work well in Swing. If it does, then whaddyaknow, cool. If > it doesn't, **** happens. If there's ever a point where I > need to decide between "keeping genericity, or making it work > better for the web", the latter is a given. > I think this is a little misleading... Rickard may say it was an accident that WW1 is decoupled from the Web, but it wasn't really an accident, it was instead a good design. For instance, the SessionMap was not a happy accident. It wraps the Session and allows the Actions to treat the HttpSession as just a Map. With Xwork we've made the distinction between the generic command framework and the web specific code more explicit. This allows us to make WebWork2 completely optimized for Web applications without worrying about polluting the core code. The design of the interceptors and plug-points in Xwork make this simple to add on top. Jason ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
