[Webwork-user] Re: WebWork & competitors...

[Rickard O. <ri...@te...>]

webwork-users mailing list is in CC.

> I would like to ask you how you're positioning WebWorks: is it a template
> engine like WebMacro? Is it an MVC framework like Struts? Are you using
JSP
> plus a taglib for the View or some template language instead?

Excellent questions. First off, a little disclaimer: I am not an expert in
WebMacro or Struts, but I have at least cursory knowledge of their design
and workings. Some of my comments may be a little off. Let me know in such
case.

WebWork has two separate parts: the first part is the Action API including
the dispatcher servlet. This is the common part of any Model-2 JSP
framework, and is similar to how Struts works. The second part is the taglib
which is not coupled to the first part really, but is simply a set of useful
tags for extracting and presenting result data. So, you could use the Action
API with another presentation technique (such as WebMacro), or you could use
the WebWork taglib with another Model-2 dispatcher (like Struts).

When I began with the foundation for WebWork I looked at other similar
technologies, such as WebMacro, Struts, XML, Turbine, etc. What I found was
that many of them had good intentions, mostly in the field of getting MVC to
work in a web environment. However, they were all flawed in one way or the
other.

For example, some of them (XMLC and Turbine for example) used the "push MVC"
paradigm where the controller code knows about the view and "pushes" data
into the presentation layer. The drawback of this pattern is that it is
tough to apply several different views to one controller, and that one often
has to rely on XML/XSLT to get multiple client type support. XML/XSLT are
complex API's, and they are rather CPU and memory intensive. The coding was
very somewhat cluttered with things that required quite a bit of knowledge
about the API being used. For me, simplicity and clean code are imperative,
and also the ability to convey the semantics of what code should do with
minimal syntax. I.e. code should be simple, short, and to the point.

Struts is probably the technique that was the most similar to WebWork. In
fact, at one point I thought "why do another framework? this looks good
enough". Approximately five seconds later I changed my mind, and realized
how wrong that was. The main problem with Struts is its large API to do
things. There is quite a bit of API in there, and it is rather tied to
Servlets (which is not strange considering that the author, Craigh
McClanahan, is obviously tainted from his work with Tomcat). The API also
imposed quite a bit of implementation rules with regard to how things are
done. I wanted an API that was smaller, simpler, was not reliant on servlets
(for the sake of reusing controller code in Swing GUI's, but also to be able
to do automatic testing outside of a servlet engine), and did not impose
unnecessary restrictions on how things are done.

The result is WebWork. The one-line technical description of WebWork is "a
Model-2 pull HMVC web application framework"(HMVC=Hierarchical Model View
Controller. "Hierarchical" since a page can be broken down into components,
and each of them uses the MVC pattern). The base API is insanely simple
(basically the execute() method in the Action interface), the application
code is not reliant on servlets (unless the ServletAware interface is used,
but it is strictly optional), there are no restrictions on what should be
used as view technique, and the application developer is free to implement
all design decisions (how to compute result view, how to choose locale, how
to perform skinning, etc.) as they please. The last point may seem awkward,
since it is too much work for all application developers to do these things
all over again for each application, but this is alleviated by introducing a
bunch of support classes which provide default, and recommended, ways of
doing things. However, if the programmer chooses he can do things from
scratch or only do some things himself (for example, he can provide a
subclass of ActionSupport that implements getView() by requesting the view
for a particular action from a database instead of using the
views.properties file, which is merely the default implementation).

Also, great care has been taken so that writing actions is easy by using a
simple execution model. Basically the actions are JavaBeans, which means
that they have setX() methods for incoming parameters, execute() is called
to perform the action, and getX() methods are lastly called to retrieve the
result data. This ensures that all actions only contain the code that is
minimally required to perform the logic. There is no extra code to account
for the fact that it is being used within WebWork.

Then, the taglibs have also been adapted to this philosophy. They only
provide tags to extract and iterate over the result data so as to present it
through HTML or similar. I will try very hard to keep the nr of tags down to
a minimum so as not to pollute this model. I do not want to introduce tags
that, for example, execute SQL queries, since this is obviously things that
should be done in the actions themselves.

Finally, due to the design of WebWork there are quite a few things that are
amazingly simple to accomplish which most other have serious difficulties
with, or cannot do at all. I am mostly thinking about custom reusable web
components (which in WebWork is just implemented as parameterized JSP
pages), and skins (which are trivially implemented by using relative JSP
references. See other post to webwork-user for details on this).

All of this together gives you an incredibly flexible model that can do,
AFAICT, all that which a web development model is supposed to handle these
days, and yet does it without requiring the developer to learn large and
complex API's such as XML and XSLT. This is equally important as developer
training is becoming increasingly problematic as the number of technologies
needed to create web sites rise. KISS is the rule we all know and love ;-)

I hope this answers your question, and then some :-)

best regards,
  Rickard