Deciding to use WW

Q: Why should I choose WebWork over other MVC frameworks out there?

A: WebWork is designed with ease of use in mind. It's small API and easy to use tag library allow you to be productive almost immediately.

Great care has been taken so that writing actions is easy by using a very simple execution model. Basically, the actions are just JavaBeans. This means that they have setX() methods for incoming parameters, an execute() method to perform the action, and getX() methods to retrieve the result data. This ensures that all actions only contain the code that is required to perform the logic. No extra code is needed to account for the fact that the JavaBean is being used within a web application.

The tag library has also adopted this philosophy. They only provide tags to extract and iterate over the result data so that formatting the output as HTML, WAP, or whatever is as straightforward as possible.

Q: I've already learned a different framework, so why should I learn another?

A: Simplicity isn't just for newbies. An easy to use, simple framework will enable you to spend more time writing business logic. If you spent a lot of time learning your current framework, chances are you will spend a lot of time keeping up to date on it.

Q: What are the design goals of WebWork?

A: WebWork has been designed and implemented with a specific set of goals, that are very important for users of it. They are as follows:


Q: What is the difference between WebWork and XMLC?

A: XMLC uses the "push MVC" paradigm where the model code knows about the view and "pushes" data into the presentation layer. The drawback of this pattern is that the controller and the view are more tightly coupled and it is difficult to support multiple views for the same controller.

WebWork uses a "pull MVC" paradigm where the model is actually just a JavaBean and the view pulls the JavaBean's attributes into itself as needed.

Q: What is the difference between WebWork and Turbine/Webmacro?

A: TODO

Q: What is the difference between WebWork and Cocoon?

A: Cocoon is an XML/XSLT web publishing framework. While XML combined with XSL is an excellent way to abstract data from presentation, it isn't really suitable for large scale application developement.

Q: What is the difference between WebWork and Struts?

A: Struts is probably the technique that was the most similar to WebWork. The main problem with Struts is its large API. There is quite a bit of API to learn, and it is closely tied to Servlet API. The Struts API also imposes quite a few implementation rules with regard to how things are done, leaving less room for customization.

The WebWork API is smaller, simpler, and is not reliant on servlets. Because the WebWork Actions aren't reliant on the Servlet API, they can be used on platforms other than web platforms, for example Swing or in a automated testing system.

Q: Isn't it slow to use tags for content generation?

A: The preferred way to generate HTML content with WebWork is to use JSP and the WebWork tag library. This allows for a very clean model and keeps Java code out of the presentation layer.

One common concern is that there is too much overhead with using tag libraries compared with using JSP's with embedded Java code. And yes, of course there is a certain amount of overhead involved. The question is whether the cost is so high that using the tags is not efficient enough.

The overhead is very dependent on which servlet engine you use. The Month list example included with WebWork uses quite a lot of tags and is therefore a decent benchmark with which you can compare different servlet engines. Simply execute the page and look at the executon time presented at the bottom of the generated page.

Here is a brief summary of running the Month list on an Athlon 650Mhz/256Mb SDRAM using a couple of popular servlet engines.

The Month list page was executed several times and the approximate mean execution time is used above. As you can see the performance varies quite a lot, so if you don't get good results it may very well be that you simply are using a poor JSP implementation.

So, overall you should be fine with using the tag libary as long as your JSP implementation is reasonably good. However, if your page is so complex that the overhead of tags becomes significant, or you're simply a speed freak, then you can always use Java code for those sections that require exceptional speed. To still be able to use WebWork comfortably you should use the methods in the dispatcher servlet to access the WebWork value stack in your JSP code.

Troubleshooting

Q: How can I search the mailing lists?

A: You can search the list archives at these locations.


Q: What JSP and Servlet Specification does WebWork require?

A: WW requires your servlet container to support JSP 1.1 and Servlet 2.3.

Q: How do install WW on WebLogic 6.1 SP2?

A: This is one way. If you have a better way, please let us know.


Q: How do install WW on WebLogic 7.0?

A: This is one way. If you have a better way, please let us know.


Q: How do install WW on Resin 2.1.1?

A: This is one way. If you have a better way, please let us know.


Q: When using WebSphere 4, it complains about an invalid tag descriptor file. What's going on?

A: WS4 cannot use tag library descriptors that are packaged in jar files. The fix is to extract the .tld file and place it in /WEB-INF instead. Change web.xml to reference it instead of the WebWork jar file. Also remember that WebSphere 4 only supports JSP 1.1 and Servlet 2.2. WW requires JSP 1.1 and Servlet 2.3.