<snip src="wiki.opensymphony.com"> WebWork’s pros include being a smaller, simpler framework, not having to build ActionForm beans, making it very simple to test your Actions, having multiple well-supported view technologies, simpler views with less JSP tags and a more powerful expression language, not having to make your Actions thread-safe, not having your Actions tied to the web, and not being part of Jakarta J. WebWork2 also adds many new features such as Interceptors, packages, IoC, etc. WebWork’s cons include being a smaller project with fewer books and less tool support, having less standards support for specs like JSTL and JSF, and not being part of Jakarta </snip>
Fair enough to a point, but Id definately disagree about struts not providing good support for using other views. There is nothing in struts that specifically makes it hard to support other view technologies - the taglibs that come with struts are purely a convienience for the majority who use JSP (theres a good argument to make them a seperate download imho) - but theres nothing anything to stop you using other things. Many people use velocity with struts - its a good fit from what I hear, and you could use pretty much any other technology too so long as that technology doesnt depend on some proprietary framework to be used with it (which would affect WW also). All the struts config objects are accessible from the servlet context and there are even toolkits for technologies such as velocity... I personally use my own homebrew rendering technology (which basically is just leveraging DOM and xhtml) and found that struts didnt get in the way and indeed meshed nicely in many cases. What I saw in the good 2 minutes or so I looked at WW just now that _did_ get me excited was the idea of it making it much easier to seperate classes from dependancies on the servlet api thus becoming easier to test. One can always test struts with things like StrutsTestCase or cactus doing mock object or in container tests, but learning how is a daunting task, which Id imagine has put off many people from trying. (I know Ive never bothered to work out how to do it - but hey, my codes so good it doesnt need testing right? ;->) If it could easily test my stuff in good old Junit using j2se... that would be sweet mate... <snip> The mapping from HTTP Request to Actions is really cohesive. You have a form with fields, you have an action with corresponding fields. </snip> Yes - theres a lot to be said for the idea of merging the actionform and the action and instantiating a new instance for each request (or reusing one from the session). Ive never fully grokked why struts was so keen to use the singleton pattern for actions. Tis true that servlets do this - and actions resemble servlets (after all they are in the end just the bit of the ActionServlet that does the specific work!) , but I and others have oft debated the merits of relaxing the threadsafety rule on actions and instantiating new ones each time - and merging the actionform into the same object so that you have a sort of 'component' perhaps follows on from this? hmmm... Can anyone think of some good reasons not to make Action an interface? -----Original Message----- From: Butt, Dudley [mailto:[EMAIL PROTECTED] Sent: Wednesday, 16 July 2003 17:08 To: [EMAIL PROTECTED] Subject: what the webwork guys say about struts BEOW IS AS IS, PASTED FROM WW forum: ===================================== Check out the docs on the Wiki (http://wiki.opensymphony.com), especially http://wiki.opensymphony.com/space/Migrating+from+Struts+1.0+to+WebWork+ 2 - migrating from Struts to WebWork2 And the article I just posted: http://wiki.opensymphony.com/space/Writeup+of+Mike%27s+Talk+at+TSS+on+We bWork2 which is a general overview of WebWork2. For your specific questions, WebWork is better than Struts because it is a simpler framework, with less ties to the web and in genral less useless contracts for your code to implement. Being less coupled makes things easier to test, which is always better. With WebWork2, we've added some very powerful features. Check the docs I listed for the overview. For the view, you can use Velocity as well as JSP, FreeMarker, JasperReports, and XML/XSLT. Velocity and JSP are the most common, and the best supported, but all are first class citizens in WW, unlike Stuts where anything but JSP is difficult. ================================================================ I use Webwork in my 'Enterprise Java' clases, largely because it is incredibly simple. One reason for this is it let's us deal JSP as a single presentation tier, which reduces the learning curve (and you can always move to something else at a later stage). The mapping from HTTP Request to Actions is really cohesive. You have a form with fields, you have an action with corresponding fields. Data gets populated and the Action is executed. It really is that simple to get started. Testing is really nice, you can run all your Actions through JUnit without being tied to the Web Container. This speeds development time as you don't need to package and deploy every time you make a change and it makes debugging much simpler. And WW2 rocks. =========================================================================== NOTICE: This message contains privileged and confidential information intended only for the person or entity to which it is addressed. Any review, retransmission, dissemination, copy or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient, is prohibited. If you received this message in error, please notify the sender immediately by e-mail, facsimile or telephone and thereafter delete the material from any computer. The New Africa Capital Group, its subsidiaries or associates do not accept liability for any personal views expressed in this message. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
