WebWork 2 : What is WebWork
This page last changed on Dec 14, 2004 by casey.
Welcome to WebWork!WebWork is a powerful web-based MVC framework built on top of a command pattern framework API called XWork. WebWork specific features include dispatchers that handle/delegate requests, result types that support several view technologies ( JSP, Velocity, JasperReports, XML, FreeMarker), and a small but powerful library of JSP tags and Velocity macros. Dispatchers invoke specified XWork actions that access and manipulate the model and provide easy access for the view to display model data. The true power of Webwork is its underlying concept of simplicity and interoperability. Using WebWork will help minimize code and allow developers to concentrate more on business logic and modeling, rather than things like building Servlets.Features
Background and PurposeWebWork is a community project conducted using the Open Source process, aimed at providing tools and a framework for building complex websites in a short amount of time, that are easy to understand and easy to maintain. Java is the platform and language upon which it is based, although it supports many others as the language in which systems are built, such as JavaScript and XML. WebWork is architecturally based upon best practices and design patterns that have proven themselves to be useful in this context. It is also based on a strong motivation to keep things as simple as possible, while maintaining flexibility (which is a difficult balancing act).It also encourages you, as a user, to do things the way you seem fit for your needs. WebWork can be configured and used in a wide range of ways, many of which are useful depending on the context. As an example of this, WebWork supports many different ways of providing the HTML generation technology, such as JSP, the Velocity template engine, and XSLT. They are all widely different, both philosophically and technologically, but can all be used with WebWork, and different users do indeed use all of these ways. "You can't do that" is a statement that we try to avoid as much as possible, and when we can't it is often because another tool would be better suited for the task. WebWork's Model-1 and Model-2 SupportOne of the most important tasks of a web application framework is to support the concept of separation of logic, content, and presentation. If this is not done one typically gets problems with maintenance, and it also makes the construction of the application more difficult if teams are involved, since each team member usually has responsibility of a particular aspect of the application. A popular way to accomplish this separation is to use the design pattern known as Model-View-Controller . This pattern enourages the separation of code into pieces that each handles the model (aka "business logic"), the controller (aka "application logic"), and the view. With this separation in place, the next question is how the controller code and the presentation should interact. There are two popular models for how to do this, which are called Model-1 and Model-2 respectively. These two are described below. Model-1The basic idea in the Model-1 approach is to invoke the controller code from within your presentation layer, e.g. the JSP's or templates. If you are using JSP's this would mean that your WebWork actions are executed by using the "webwork:action" custom tag, or by invoking regular JavaBeans using the "webwork:bean" tag. Model-2In the Model-2 approach, the decision of what code to call and what view to present is determined by a third party, normally a servlet dispatcher. The dispatcher will decode the URL of the HTTP request, and determine what code to execute. A Java object representing the controller code is retrieved and executed, thus performing some custom application logic and business logic processing. After the execution is done, the dispatcher forwards the request to a view handler (for example a JSP), which then renders the result view using the data from the previous processing. When to use what?Since the controller logic and presentation generation is completely decoupled, it is possible to show different result pages depending on how the execution went. For example, if the processing went wrong an error page might be shown instead of the usual result page. The benefits of the Model-1 approach are as follows.
The benefits of the Model-2 approach are as follows.
A general rule of thumb of when to use what is to use Model-1 for read-type code that can only result in the retrieved data being showed, and use Model-2 whenever the model is updated by the action or a process flow is being done. |
![]() |
Document generated by Confluence on Dec 14, 2004 16:37 |