Recommendations for a web application framework?

[Alan Meyer]

We're starting a new project to put an interactive data entry and
publishing system on the web. Users will enter inputs of many
types and will get back responses from a database depending on
their inputs. The system will be developed using Linux, Java,
JSP, and MySQL.

There are a number of Java based web application frameworks that
look like they might reduce the total effort involved in the
task. Some that I've briefly looked at include:

Struts "classic" (currently version 1.2.8)
Struts Shale (currently 1.2.9)
Webwork (currently 2.2.2 and eventually to become Struts 2.0)
Spring (currently 1.2.8 but 2.0 in release candidate form)

There are others too, including one called Tapestry, that I have
not looked at.

My impressions so far are:

Struts "classic" is far and away the most used of the
frameworks, but also the oldest technology and development
appears to be slowing down or ending.

Webwork is thought by the Struts team to be better than
Struts, which is why they are switching to it.

Spring is second in popularity. It appears to included
component parts that are sometimes selected out and used with
other frameworks.

Shale is the most "different" of the group.

The whole Struts heritage - classic, Shale, and Webwork - is
in a state of some confusion. It is not clear where the
majority of Struts users will go and which of the projects
will have long term continued support.

My criteria for selection are:

1. Robustness. We don't want to fight a lot of bugs in the code.

2. Community support. We would like an active user and developer
community and hope that the framework doesn't become obsolete
and abandoned.

3. Power. We want something that saves us development time.

4. Flexibility. We want a framework that allows us to do
whatever needs to be done, even if it turns out that the
original framework designers didn't contemplate doing this
thing.

5. AJAX support. We're very interested in this new technology
and would like the package we select to both integrate well
with it and make it easy to use.

Does anyone have recommendations for us - either for or against
any particular package?

Thanks.

Alan

 

[Danno]

We're starting a new project to put an interactive data entry and
publishing system on the web. Users will enter inputs of many
types and will get back responses from a database depending on
their inputs. The system will be developed using Linux, Java,
JSP, and MySQL.

There are a number of Java based web application frameworks that
look like they might reduce the total effort involved in the
task. Some that I've briefly looked at include:

Struts "classic" (currently version 1.2.8)
Struts Shale (currently 1.2.9)
Webwork (currently 2.2.2 and eventually to become Struts 2.0)
Spring (currently 1.2.8 but 2.0 in release candidate form)

There are others too, including one called Tapestry, that I have
not looked at.

My impressions so far are:

Struts "classic" is far and away the most used of the
frameworks, but also the oldest technology and development
appears to be slowing down or ending.

Webwork is thought by the Struts team to be better than
Struts, which is why they are switching to it.

Spring is second in popularity. It appears to included
component parts that are sometimes selected out and used with
other frameworks.

Shale is the most "different" of the group.

The whole Struts heritage - classic, Shale, and Webwork - is
in a state of some confusion. It is not clear where the
majority of Struts users will go and which of the projects
will have long term continued support.

My criteria for selection are:

1. Robustness. We don't want to fight a lot of bugs in the code.

2. Community support. We would like an active user and developer
community and hope that the framework doesn't become obsolete
and abandoned.

3. Power. We want something that saves us development time.

4. Flexibility. We want a framework that allows us to do
whatever needs to be done, even if it turns out that the
original framework designers didn't contemplate doing this
thing.

5. AJAX support. We're very interested in this new technology
and would like the package we select to both integrate well
with it and make it easy to use.

Does anyone have recommendations for us - either for or against
any particular package?

Thanks.

Alan

I like what stripes is offering as far as what you need, it is
lightweight and flexible, and you don't need to marry another
technology or thought.

 

[Chris Smith]

There are a number of Java based web application frameworks that
look like they might reduce the total effort involved in the
task. Some that I've briefly looked at include:

Struts "classic" (currently version 1.2.8)
Struts Shale (currently 1.2.9)
Webwork (currently 2.2.2 and eventually to become Struts 2.0)
Spring (currently 1.2.8 but 2.0 in release candidate form)

There are others too, including one called Tapestry, that I have
not looked at.

Tapestry is popular, but there's a far more important option that you've
left off, and that's plain JSF. JSF is a very powerful framework for
developing web applications, and is quite competitive with all of the
options above.

A few notes about Shale: (Note: this is contentious and admittedly
exaggerated.) Essentially, Shale is an ego-trip by a few people who had
the courage to understand that JSF is a powerful framework that meets
most web application development needs, but then lapsed back into the
past. It offers strange mixes of JSF with alternative designs, and the
result is really rather a big mess. Essentially, you've got a core of
JSF, plus:

1. ViewController backing beans, because we couldn't quite face the
death of Action classes or understand event-based programming.

2. Dialog Manager, because we couldn't quite get our hands off the
navigation system.

3. Tiles integration, because even though custom tag files have made
Tiles irrelevant for new projects, Mr. Geary can't let go.

4. Application Manager, because we really need TWO different
simultaneous request processing lifecycles. (Subtitle: also because
some of us were just too attached to the Commons Chain project and
thought it'd be fun to add another unnecessary dependency on an external
project.)

5. Remoting: We wanted to say we support AJAX, but we haven't quite
figured out how yet... and meanwhile, ajax4jsf has implemented a quite
flexible JSF/AJAX framework, but we didn't know that was going to happen
when we started.

6. Clay, because we decided we really don't like JSF too awfully much
anyway.

And then there's the one useful feature, which is Commons Validator
integration. At one point, it was possible to extract that out and use
it without the rest of Shale... but I'm not quite sure about the current
status of that approach.

So anyway, I'd look into JSF and the ajax4jsf project from SourceForge,
both of which are thriving and quite a popular and fully-featured way to
handle development of web applications.

The whole Struts heritage - classic, Shale, and Webwork - is
in a state of some confusion. It is not clear where the
majority of Struts users will go and which of the projects
will have long term continued support.

This is largely due to the influence of JSF, which is now a standard
technology that's part of J2EE, available out of the box on all current
versionsof application servers and freely available where it's not
already there, and meets basically all of the major needs that drove
people to these third-party frameworks in the past.

Nevertheless, there are definite advantages to some of the alternative
frameworks. Spring-MVC is obviously going to integrate better with a
Spring-based back end. Tapestry is a little lighter-weight in terms of
its impact on your view layer development. I'd avoid Shale or Struts
Classic. I don't know much about WebWork at this point.

 

[Alan Meyer]

...
I like what stripes is offering as far as what you need, it is
lightweight and flexible, and you don't need to marry another
technology or thought.

Yipes! Stripes!

I didn't even know that one existed. But I'll probably stay more
mainstream. Trying to evaluate everything takes more effort
than I can afford.

Thanks.

Alan

 

[Alan Meyer]

Chris,

Thank you very much for the candid comments.

One of the problems we have in reading evaluations is that
most writers bend over backwards to be fair to everyone -
which is good in a way. But sometimes a little candor is
more helpful.

Alan

 

[jamespcooper]

Alan,

I would concur that JSF is definitely worth looking into. Be aware
that JSF requires Javascript to be enabled on the client. If you turn
off Javascript in your browser commandLink and commandButton controls
(i.e. all JSF aware URLs and form submit buttons) will no longer work.

-- James

 

[Timo Stamm]

Yipes! Stripes!

I didn't even know that one existed. But I'll probably stay more
mainstream. Trying to evaluate everything takes more effort
than I can afford.

There are several dozens of java web frameworks, and they are all
different. It would take you months to get to know them all.


I recommend having a look at Wicket (http://wicket.sourceforge.net).
It's features are:

- Very clean separation of HTML and Java code - the HTML can be edited
with WYSIWYG editors without any side-effects.

- Component-oriented - very good reusability.

- Plain old Java - no XML configuration files, no programming in XML.

 

[David Segall]

We're starting a new project to put an interactive data entry and
publishing system on the web. Users will enter inputs of many
types and will get back responses from a database depending on
their inputs. The system will be developed using Linux, Java,
JSP, and MySQL.

There are a number of Java based web application frameworks that
look like they might reduce the total effort involved in the
task. Some that I've briefly looked at include:

Struts "classic" (currently version 1.2.8)
Struts Shale (currently 1.2.9)
Webwork (currently 2.2.2 and eventually to become Struts 2.0)
Spring (currently 1.2.8 but 2.0 in release candidate form)

There are others too, including one called Tapestry, that I have
not looked at.

Did you have a reason for omitting Java Server Faces? I confess that I
"chose" it because it is the required framework for using Sun's web
application RAD tool
<http://developers.sun.com/prodtech/javatools/jscreator/index.jsp>.
However, it seems to be the framework of choice both at Sun
<http://java.sun.com/javaee/javaserverfaces/index.jsp> and at Oracle
<http://www.oracle.com/technology/obe/ADF_tutorial_1013/index.htm>.

 

[Alan Meyer]

...
Did you have a reason for omitting Java Server Faces? I confess that I
"chose" it because it is the required framework for using Sun's web
application RAD tool
<http://developers.sun.com/prodtech/javatools/jscreator/index.jsp>.
However, it seems to be the framework of choice both at Sun
<http://java.sun.com/javaee/javaserverfaces/index.jsp> and at Oracle
<http://www.oracle.com/technology/obe/ADF_tutorial_1013/index.htm>.

I did not have a good reason for omitting it. Since you're the second
person recommending it, I am looking into it.

Do you or Chris think that using JSF is better than using, say,
Webwork or Spring? Or perhaps that it's just another approach?

In your use of JSF, have you ever felt that it forbids you from doing
something that you really think you should do?

Thanks.

Alan

 

[Chris Smith]

Do you or Chris think that using JSF is better than using, say,
Webwork or Spring? Or perhaps that it's just another approach?

I definitely feel that JSF is a better idea than Spring-MVC. I don't
know much about WebWork, but I'm pretty skeptical of new revolutionary
web application frameworks these days. One huge advantage of JSF (in my
view) that applies versus most anything else is that it is the standard
framework for web application development with Java. As such, I would
need a pretty good reason to switch away from it. I haven't seen
anything else that really is such a good reason.

JSF does an excellent job of separation of concerns. Although this has
been a major motivating goal of pretty much all major web application
frameworks, all of them that I've seen have fallen short until JSF came
around. With JSF, I can actually build my entire Java code without
having to think about the view layer at all; and I can build the view
layer while only worrying about the specific set of documented
properties and methods of backing beans. In almost everything else, you
have to do this naming convention junk between "form beans" and HTML
forms, and the form beans are not really all that abstracted from basic
HTTP parameter handling. With JSF, all that logic goes into the view
layer, whether it's JSPs or component implementations, and properly
converted and meaningful data is injected into backing beans from the
view, which the application can then handle from appropriate event
handlers. That's a HUGE advantage. Perhaps it sounds a tad trivial,
but it eliminates the biggest pains of real-world application
development when you no longer have to maintain simultaneous naming
conventions between Java code and JSP pages.

In your use of JSF, have you ever felt that it forbids you from doing
something that you really think you should do?

There are three major disadvantages to JSF:

a) It is a bit too intrusive on the view layer. While views can be
developed separately from application logic, they do need to be
developed using JSF components instead of HTML tags. This means that if
your model has been to have your graphic design department build HTML
pages and then go make the minimal changes to incorporate them into the
application, you'll have to change that a bit. Tapestry does a better
job of being unobtrusive, but at the cost of complexity elsewhere.

b) It limits your potential technology support and your use of the full
range of HTTP features. The two biggest limitations are that JSF
currently doesn't work at all with GET-style HTTP requests (unless this
has changed in 1.2), and that the JSP component bindings pretty well
require that the client have JavaScript enabled.

c) The Java APIs are rather weak in abstraction. The implementation
details of the container show through in a lot of places. This is
unnecessary, and makes JSF code appear messy sometimes.

 

[Alan Meyer]

Thanks Chris. That's an excellent reply to my questions.

I appreciate your help.

Alan

 

[Timo Stamm]

I definitely feel that JSF is a better idea than Spring-MVC. I don't
know much about WebWork, but I'm pretty skeptical of new revolutionary
web application frameworks these days. One huge advantage of JSF (in my
view) that applies versus most anything else is that it is the standard
framework for web application development with Java. As such, I would
need a pretty good reason to switch away from it. I haven't seen
anything else that really is such a good reason.

JSF does an excellent job of separation of concerns.

Do you mean separation of HTML and Java or separation of business
objects and view code? In my opinion, even PHP template libraries like
TAL do a better job of separation in both respects than JSF.

[...] With JSF, I can actually build my entire Java code without
having to think about the view layer at all; [...] In almost everything
else, you have to do this naming convention junk between "form beans"
and HTML forms, and the form beans are not really all that abstracted
from basic HTTP parameter handling.

That's Struts. But Struts is the oldest (and most outdated) of all Java
Web Frameworks I know. There are many Frameworks that hide HTTP
entirely. With some, you don't even have to care about request-response
cycles: Let's say that I want to display a number on a web page, and
increase the number by 1 everytime the user clicks a link. Using Struts,
you would probably store the value in the session.

In a more advanced framework, it might look like this:

Java code:

public class CounterPage extends WebPage {

public int counter = 0;

public CounterPage() {
add(new Link("increase") {

public void onClick() {
counter = counter + 1;
}
});
add(new Label("counter", new PropertyModel(this, "counter")));
}
}


HTML:

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:wicket="http://wicket.sourceforge.net/">
<head>
<title>Counter Page</title>
</head>
<body>
<span wicket:id="counter">[counter value will appear here]</span>
<a wicket:id="increase">increase counter</a>
</body>
</html>


Model and view are glued together by simple Classes. In this case, a
OGNL expression is used.


JSF is just too complicated for my taste, but it certainly is the best
choice for large applications because it is the official standard, has
support of many vendors and a many available programmers.


Timo

 

[Chris Smith]

Do you mean separation of HTML and Java or separation of business
objects and view code?

I meant separation of view code from application code. I try to avoid
words like "business logic" or "business objects", but you could assume
that we mean about the same thing. I did contribute some confusion,
though, by saying "I can actually build my entire Java code..." when I
really should have said that I can write the core application in a way
independent of the user interface. JSF *does* include Java in the view
module; but the interesting separation is between view and application
logic, not between Java and JSP/HTML/etc.

In my opinion, even PHP template libraries like
TAL do a better job of separation in both respects than JSF.

I'm convinced, then, that we are talking about different things. TAL
doesn't even get you halfway there. It's nothing more than an
abbreviation language for encoding PHP control structures into special
"tal:" attributes. It does nothing about the need to keep form
parameter names in sync between code that uses them and HTML that
generates them. It similarly does nothing about converting the data
from weird HTML for encoding rules into reasonable high-level data
structures in the web application. These are things that tie together
application code and the view, and the manual maintenance is a huge
source of hassles.

That's Struts. But Struts is the oldest (and most outdated) of all Java
Web Frameworks I know.

In a different form, it's also the Wicket example you posted, which has
two id attributes in the page corresponding to the two components; and
then a Java class representing that page, which again has to match the
id attributes on components on the page. It's a little better than
Struts, to be sure. Yet I still see this duality wherein there's a Java
class representing the form.

There are many Frameworks that hide HTTP
entirely. With some, you don't even have to care about request-response
cycles:

For most common purposes, JSF could be included in that category. JSF
does define a request processing lifecycle, but typical application code
just defines event listeners and they get called at the right time. You
have to know a few things (for example, say, that converters get called
before validators) but this is more about the JSF model than HTTP
request processing. The request processing lifecycle becomes more
important when you're generating non-JSF content (such as dynamically
generated images and such), or when you're pulling more advanced tricks
such as when I wrote a JSF component to interact with JSF backing beans
straight from JavaScript in a web page, and needed to prevent the
rendering of an HTML response to that HTTP request. I wonder how I
would have accomplished something like that if JSF hid the request
processing lifecycle just a little more.

 

[Timo Stamm]

I meant separation of view code from application code. I try to avoid
words like "business logic" or "business objects", but you could assume
that we mean about the same thing.

I think so.

I'm convinced, then, that we are talking about different things. TAL
doesn't even get you halfway there. It's nothing more than an
abbreviation language for encoding PHP control structures into special
"tal:" attributes.

I admit that was an unjust exaggeration. TAL does a better job of
separating the HTML Template from view code than JSP. But TAL certainly
can't compete with JSF because it is just a template library, not a
component oriented web framework.

In a different form, it's also the Wicket example you posted, which has
two id attributes in the page corresponding to the two components; and
then a Java class representing that page, which again has to match the
id attributes on components on the page. It's a little better than
Struts, to be sure. Yet I still see this duality wherein there's a Java
class representing the form.

Unfortunately, you can not eliminate this duality if you want to use
HTML templates and insert a value into a specific position in the template.

But with wicket, you could encapsulate the two components for the link
and the output label into one component and you can use language
features like inheritance to remove redundancy (yes, it works with HTML
templates too because a HTML file is always associated with a java class).

For most common purposes, JSF could be included in that category. JSF
does define a request processing lifecycle, but typical application code
just defines event listeners and they get called at the right time. You
have to know a few things (for example, say, that converters get called
before validators) but this is more about the JSF model than HTTP
request processing.

This is a major problem with JSF to me: You have to define a lot of
classes and XML configuration files. You have to solve too many problems
that are not part of the intrinsic problem, but are introduced by the
framework that you utilize to solve the intrinsic problem.

The example I gave requires one additional class to represent the
Application and one entry in the deployment descriptor to get it
running. An implementation in JSF would probably require at least twice
as many files. I feels like having to work for the framework instead of
solving problems.

The request processing lifecycle becomes more
important when you're generating non-JSF content (such as dynamically
generated images and such), or when you're pulling more advanced tricks
such as when I wrote a JSF component to interact with JSF backing beans
straight from JavaScript in a web page, and needed to prevent the
rendering of an HTML response to that HTTP request.

Was that before JSF 1.2? As far as I understand, the "Avatar" Extension
should make AJAX (forgive me using the buzzword) easier.


Timo

 

[David Segall]

I did not have a good reason for omitting it. Since you're the second
person recommending it, I am looking into it.

Do you or Chris think that using JSF is better than using, say,
Webwork or Spring? Or perhaps that it's just another approach?

I am too inexperienced with both web applications and Java to compare
the frameworks you have listed. I regret to say that I have given you
an exhaustive list of my reasons for choosing JSF above. My question
about the omission was because I feared that I might have made a gross
error with my choice.

In your use of JSF, have you ever felt that it forbids you from doing
something that you really think you should do?

As it happens I do have an example. I need to have users confirm their
registration at a web site and the only convenient way I can think of
is to send them a URL that includes GET method data. However, JSF
seems to insist on POST method parameters. I have a solution but it is
not very tidy.

 

[Chris Smith]

Unfortunately, you can not eliminate this duality if you want to use
HTML templates and insert a value into a specific position in the template.

I think it is avoidable, and I think JSF does it.

To be perhaps a little clearer, what JSF does is ensure that the
correspondence between identifiers and names in Java code and HTML
content is one-way. That eliminates the really painful bit, which is to
try and keep stuff in sync. I can actually write a JSF backing bean
that encapsulates what I need to know in order to perform some task...
and I really don't care whether the user interface gathers that
information (a) with one component or another; (b) with a single HTML
page or in a wizard-style interface across several pages; etc. Instead,
I create and publish my interface in the form of a backing bean, and
then the web design can be done along those lines. Those changes to the
user interface part of the application are performed simply by binding
different JSF components to different backing bean properties. The
backing beans only need to be changed if there's a real change, such as
the need to enter additional information that the application doesn't
know how to handle yet.

But with wicket, you could encapsulate the two components for the link
and the output label into one component and you can use language
features like inheritance to remove redundancy (yes, it works with HTML
templates too because a HTML file is always associated with a java class).

It's exactly that -- an HTML file is always associated with a Java class
-- that bothers me. I think that's a serious problem. My Java code
shouldn't care what HTML files exist in the application.

This is a major problem with JSF to me: You have to define a lot of
classes and XML configuration files.

Hmm? In addition to the web application deployment descriptor, you have
to add one XML file. I don't like XML for configuration too awfully
much, but the actual information in that file is quite meaningful. It
consists mainly of the navigation scheme between pages, and the model of
information that is available to the pages. I actually wish these were
in different files, since they express facts that are useful in
different parts of the development process; but I imagine that didn't
happen in order to avoid the issue of too many configuration files. In
any case, you can still do things that way manually.

As for classes, I'm willing to wager that there are fewer classes
involved in a JSF implementation of something that with anything that
requires a Java class dual for each

Are you referring to the need to declare backing beans in
faces-config.xml? That would be the key to avoiding the need for the
class per web page model, in that it allows the view layer to access
whatever data it needs based on declared interfaces; and conversely, the
model layer to look in well-defined places for information regardless of
what HTML page it came from.

The example I gave requires one additional class to represent the
Application and one entry in the deployment descriptor to get it
running. An implementation in JSF would probably require at least twice
as many files.

It would require:

1. WEB-INF/web.xml
2. WEB-INF/faces-config.xml
3. counter.jsp
4. WEB-INF/classes/.../CounterBean.java

Furthermore, none of these are really all that involved. web.xml would
contain a mapping for the faces servlet, and possibly some configuration
if you want to change the defaults. faces-config.xml would contain one
navigation rule and one backing bean declaration for CounterBean. The
counter.jsp file would contain the view code, and would bind the
components to CounterBean via EL expressions. Finally, CounterBean
would contain one method to increment the counter variable, and another
to get the counter variable for display.

(The way I typically write JSF code, there would also be an index.jsp
that just contains a single <jsp:forward> action. That's not necessary,
but if it weren't there, you'd need to modify web.xml to change the
welcome file list so that it loads "counter.jsf" by default.)

Was that before JSF 1.2? As far as I understand, the "Avatar" Extension
should make AJAX (forgive me using the buzzword) easier.

It was prior to JSF 1.2. I haven't looked into JSF 1.2 yet, though it's
on my list of things to do this weekend.

 

[Timo Stamm]

I think it is avoidable, and I think JSF does it.

To be perhaps a little clearer, what JSF does is ensure that the
correspondence between identifiers and names in Java code and HTML
content is one-way. That eliminates the really painful bit, which is to
try and keep stuff in sync.

Yes, JSF avoids the duality because it doesn't really have templates.
You don't have to bind a component to a position in the template, you
define components directly in the JSP code using taglibs, and this
introduces problems:

- It is impossible to use HTML mockups from a web designer without major
changes that render them useless to the web designer.

- Browser incompatibilies are annoying. Having to debug them on a
running application instead of the actual HTML file makes the issue worse.

- It forces you to express logic in a XML language. Java may have a
verbose syntax, but it's still much better than XML, especially with a
decent IDE.

I can actually write a JSF backing bean
that encapsulates what I need to know in order to perform some task...
and I really don't care whether the user interface gathers that
information (a) with one component or another; (b) with a single HTML
page or in a wizard-style interface across several pages; etc. Instead,
I create and publish my interface in the form of a backing bean, and
then the web design can be done along those lines. Those changes to the
user interface part of the application are performed simply by binding
different JSF components to different backing bean properties. The
backing beans only need to be changed if there's a real change, such as
the need to enter additional information that the application doesn't
know how to handle yet.

The equivalent in the wicket world is called a "model object". But you
don't access it from the template, but from the java code. There has
been support to do make model properties available via OGNL (roughly
similar to the JSP EL), but the usage is discouraged and I don't even
know if the feature is still available.

It's exactly that -- an HTML file is always associated with a Java class
-- that bothers me. I think that's a serious problem. My Java code
shouldn't care what HTML files exist in the application.

That is exactly what I was thinking when I had a first look at Wicket. I
am somewhat allergic to redundancy and was very dubious about the need
to tell the framework twice that I want a component there. But in
practice, it really isn't an issue because there are so many ways to
remove the redundancy and it isn't really as bad as it looks.

For example, I would create a base page class for a project, that
contains common elements like navigation and a footer. This page class
would be extended by the actual pages. The subclasses only have to take
care of their contribution, and they may not even need any associated
HTML files, because the HTML template associated with the super class is
reused.

The same can be applied to components. You do not need a HTML template
for each and every component.

In practice, I spend very little time maintaining the HTML templates.

Hmm? In addition to the web application deployment descriptor, you have
to add one XML file. I don't like XML for configuration too awfully
much, but the actual information in that file is quite meaningful. It
consists mainly of the navigation scheme between pages, and the model of
information that is available to the pages. I actually wish these were
in different files, since they express facts that are useful in
different parts of the development process; but I imagine that didn't
happen in order to avoid the issue of too many configuration files. In
any case, you can still do things that way manually.

As for classes, I'm willing to wager that there are fewer classes
involved in a JSF implementation of something that with anything that
requires a Java class dual for each

Are you referring to the need to declare backing beans in
faces-config.xml? That would be the key to avoiding the need for the
class per web page model, in that it allows the view layer to access
whatever data it needs based on declared interfaces; and conversely, the
model layer to look in well-defined places for information regardless of
what HTML page it came from.


It would require:

1. WEB-INF/web.xml
2. WEB-INF/faces-config.xml
3. counter.jsp
4. WEB-INF/classes/.../CounterBean.java

Furthermore, none of these are really all that involved.

I stand corrected, you don't have to define twice as many files.

My memory might have played me a trick, because working with JSF sure
felt like having to do at least twice as much work

web.xml would
contain a mapping for the faces servlet,

Wicket requires the mapping for the wicket servlet, and the class name
of the Application class.

and possibly some configuration
if you want to change the defaults.

You configure Wicket applications in the Wicket application class.

faces-config.xml would contain one
navigation rule

Not necessary. In Wicket, pages are plain Java objects and you can
navigate with plain Java code:

setResponsePage(new MyPage());

If you really need to maintain navigation paths in an XML file, you can
easily create you own method that looks the target up in an XML file.
But I doubt that most real world application require this.

and one backing bean declaration for CounterBean.

Not necessary.

The
counter.jsp file would contain the view code,

This would be equivalent to the CounterPage.java + CounterPage.html
files of my example. Wicket needs one more file.

and would bind the
components to CounterBean via EL expressions.

I don't need a CounterBean, just an int, but it has to be bound via OGNL
(similar to EL).

Finally, CounterBean
would contain one method to increment the counter variable, and another
to get the counter variable for display.

Not necessary, I can simply override Link#onClick(). It would be trivial
to write a Link component that uses it's id as a the name of a method
that should be called on a model object, but I never needed to.

(The way I typically write JSF code, there would also be an index.jsp
that just contains a single <jsp:forward> action. That's not necessary,
but if it weren't there, you'd need to modify web.xml to change the
welcome file list so that it loads "counter.jsf" by default.)

In your Application class constructor:

setHomePage(MyHomePage.class);


But that was a very simple example. The fun starts when you want to
create your own components to avoid copy-and-paste code.

It is quite some time ago that I worked with JSF, but I think these
steps are necessary to create a new component (please correct me if I'm
wrong):

- implement StateHolder

- define a renderer (no standard template system available)

- create component type identifier

- register the component in faces-config.xml using the class name and
component type identifier

- create a custom tag library XML descriptor with all attributes, again
repeating the class name and introducing yet another identifier

- add taglib in JSP header before using it


This list is missing event handling and composite components.


In contrast to this, let's have a look at what I have to do to combine
the two components of my example into one reusable component:

- Create a new class and copy the code from CounterPage.


That's how it looks:

class CounterComponent extends WebMarkupContainer {

public int counter = 0;

public CounterComponent(String id) {
super(id);
add(new Link("increase") {

public void onClick() {
counter = counter + 1;
}
});
add(new Label("counter", new PropertyModel(this, "counter")));
}
}

That's how it will be used:

add(new CounterComponent("mycounter"));


I know that JSF has it's advantages, but it would be nice if it didn't
make trivial stuff so very complicated.


Timo