Guillermo Castro has written up Wicket, in "Comparing Web Frameworks: Wicket," based on Simon Brown's series of articles comparing web frameworks.

Brown put forth a set of requirements and a domain model, and has written up a series of implementations (Model 1 with scriptlets, Model 1 with JSTL, Model 1 with JSP XML, Struts, and Guillermo volunteered to offer a Wicket implementation, following Mr. Brown's model of explaining the core concepts behind each framework and showing code.

Based on the sample code, some of the concepts behind Wicket mirror similar concepts as implemented by Tapestry and other such frameworks that replace tagged content in HTML.

That said, Mr. Castro summarizes:

Wicket, in my opinion, focuses the development efforts in the right place, inside plain Java code, and leaves the graphical presentation where it should be, inside html. At first you might find a little hard to grasp this paradigm shift, as so many developers are being 'forced' to rely on jstl and jsp scriptlets to accomplish logic programming for a page with all the other frameworks. But once you get used to this, I'm sure wicket will provide really fast development times.

The similarity of this project to the Sourceforge-hosted Wafer Project is hard to miss (provided, of course, you remember the Wafer Project!) and it'd be interesting to see further development with the comparison points in mind.

I a going to agree with some previous commenters on Simon's blog that read-only sample is not enough to show difference between the frameworks. Even more so, a primitive two-page read-only application makes both Struts and Wicket look like a 300lb gorilla in a miniature JSP+JSTL shop.

Some kind of input processing is needed, even the basic one. It would show how the state is managed, how errors are handled, how modules interact, how Back button is supported, all kind of things that is important for an interactive application, not for a readonly website.

There is another example (crud) comparing struts and wicket here: http://learntechnology.net/ It uses a pre-beta snapshot of wicket 1.2 so some things have been improved between now and then on the wicket front.

Does anybody have some good links discussing the merits of page based frameworks (struts, spring, webwork, asp) versus component based frameworks (wicket, tapestry, echo, jsf?, asp.net)?

Does anybody have some good links discussing the merits of page based frameworks (struts, spring, webwork, asp) versus component based frameworks (wicket, tapestry, echo, jsf?, asp.net)?

My address at the ServerSide Symposium (March 23-25) will address some of this, but from a pretty high level viewpoint. In the mean time, there's a JSF+Shale version of the canonical "Struts MailReader" example (simple two-page CRUD) available on the Shale nightly downloads page. Comparing it to the standard Struts 1.2.8 version is one way to get a feel for at least the JSF versus Struts part of this question.

Craig

Does anybody have some good links discussing the merits of page based frameworks (struts, spring, webwork, asp) versus component based frameworks (wicket, tapestry, echo, jsf?, asp.net)?

I would not call Struts, Spring MVC or WebWork as page-based frameworks. Page-based frameworks are ASP, ASP.NET; less so JSF and Wicket because they support subviews/panels and promote their usage. Instead of working with pieces of Model that accept input and render themselves, these frameworks concentrate on the View, turning MVC into VCM. Which is not necessarily a bad thing.

Does anybody have some good links discussing the merits of page based frameworks (struts, spring, webwork, asp) versus component based frameworks (wicket, tapestry, echo, jsf?, asp.net)?

I would not call Struts, Spring MVC or WebWork as page-based frameworks. Page-based frameworks are ASP, ASP.NET; less so JSF and Wicket because they support subviews/panels and promote their usage. Instead of working with pieces of Model that accept input and render themselves, these frameworks concentrate on the View, turning MVC into VCM. Which is not necessarily a bad thing.

WebWork can support both the standard MVC paradigm with action first, and a page view controller paradigm like .NET with the ActionTag, which lets you execute the action from the page and optionally have the action's rendered output put into the page. And of course you can combine the two, using the main action for the main processing and the action tag to encapsulate reusable UI components.

Jason, compared to Wicket, Tapestry, and JSF-- WebWork does not have components. They are more like easy tags.

Jason, compared to Wicket, Tapestry, and JSF-- WebWork does not have components. They are more like easy tags.

In that it doesn't have a complex lifecycle and UI component model, yes. In terms of reusable UI pieces, it does.

Jason, compared to Wicket, Tapestry, and JSF-- WebWork does not have components. They are more like easy tags.

In that it doesn't have a complex lifecycle and UI component model, yes. In terms of reusable UI pieces, it does.

Yes, the 'UI pieces' offer the same functionality as component frameworks ;-)

Jason, compared to Wicket, Tapestry, and JSF-- WebWork does not have components. They are more like easy tags.

In that it doesn't have a complex lifecycle and UI component model, yes. In terms of reusable UI pieces, it does.

Yes, the 'UI pieces' offer the same functionality as component frameworks ;-)

A user does not know what happens on the server, so... why not? For example, these components are pure JSP (with some custom taglibs, of course) and can be included into any JSP page.

Does anybody have some good links discussing the merits of page based frameworks (struts, spring, webwork, asp) versus component based frameworks (wicket, tapestry, echo, jsf?, asp.net)?

I would not call Struts, Spring MVC or WebWork as page-based frameworks. Page-based frameworks are ASP, ASP.NET; less so JSF and Wicket because they support subviews/panels and promote their usage. Instead of working with pieces of Model that accept input and render themselves, these frameworks concentrate on the View, turning MVC into VCM. Which is not necessarily a bad thing.

WebWork can support both the standard MVC paradigm with action first, and a page view controller paradigm like .NET with the ActionTag, which lets you execute the action from the page and optionally have the action's rendered output put into the page. And of course you can combine the two, using the main action for the main processing and the action tag to encapsulate reusable UI components.

Jason,

Can you send links to sample code that uses these WebWork style components?

Is there a "getting started with WebWork page (?) components" page that I can read?

Is this technique covered in WebWork in Action?

Jason,Can you send links to sample code that uses these WebWork style components?Is there a "getting started with WebWork page (?) components" page that I can read?Is this technique covered in WebWork in Action?

Yes, it's covered in WebWork in Action. I haven't had time to be part of the documentation effort in a while, so I'm not sure where to send you to, but this is a pretty common usage of the ww:action tag.

Jason,Can you send links to sample code that uses these WebWork style components?Is there a "getting started with WebWork page (?) components" page that I can read?Is this technique covered in WebWork in Action?

Yes, it's covered in WebWork in Action. I haven't had time to be part of the documentation effort in a while, so I'm not sure where to send you to, but this is a pretty common usage of the ww:action tag.

Jason,

When I google the webwork site for webwork components, I don't get much.

Here is the google search.....
http://www.google.com/search?hl=en&lr=&q=webwork+components+site%3Awww.opensymphony.com&btnG=Search

I get this, but it does not seem like what you are talking about....
http://www.opensymphony.com/webwork/wikidocs/Using%20WebWork%20Components.html

I assume this is covered in the samples or something.

Yes, there is some confusion regarding IoC components and the UI components; what you are looking for is this: http://wiki.opensymphony.com/display/WW/component

Probably WW's best kept secret.

Yes, there is some confusion regarding IoC components and the UI components; what you are looking for is this: http://wiki.opensymphony.com/display/WW/componentProbably WW's best kept secret.

Thanks for the link. I am happily stuck in JSF/Facelet world, but one never knows when your world will change. This is something I am interested in looking into in any regards. I went to the link and read the page. It does seem like something I would use if ever in the world of WebWork (and soon Struts 2.0).

Does anybody have some good links discussing the merits of page based frameworks (struts, spring, webwork, asp) versus component based frameworks (wicket, tapestry, echo, jsf?, asp.net)?

I would not call Struts, Spring MVC or WebWork as page-based frameworks. Page-based frameworks are ASP, ASP.NET; less so JSF and Wicket because they support subviews/panels and promote their usage. Instead of working with pieces of Model that accept input and render themselves, these frameworks concentrate on the View, turning MVC into VCM. Which is not necessarily a bad thing.

WebWork can support both the standard MVC paradigm with action first, and a page view controller paradigm like .NET with the ActionTag, which lets you execute the action from the page and optionally have the action's rendered output put into the page. And of course you can combine the two, using the main action for the main processing and the action tag to encapsulate reusable UI components.

Right, "view helper" thing. The same approach is used in Stripes. Stripes is simpler, though, with annotations, dispatch-type request processing and no XML. And (surprise, surprise!) "view helper" pattern can be used in Struts Classic as well:
  <jsp:include page="/viewhelper.do" />
where corresponding action class initializes whatever objects are needed to be initialized, and returns null instead of ActionForward object. No ActionTag needed.

Yeah nothing against Wicket (or WebWork or Struts - whatever) but Stripes is really slick. If you have not yet scoped it out it is worth a look.

Yeah nothing against Wicket (or WebWork or Struts - whatever) but Stripes is really slick. If you have not yet scoped it out it is worth a look.

I like what I have seen from Stripes. In this comparison it would be of type 'Hybrid Component/Action Frameworks'. Different from Wicket in several ways, but I think both frameworks share the code-centric approach.

Yeah nothing against Wicket (or WebWork or Struts - whatever) but Stripes is really slick. If you have not yet scoped it out it is worth a look.

I like what I have seen from Stripes. In this comparison it would be of type 'Hybrid Component/Action Frameworks'. Different from Wicket in several ways, but I think both frameworks share the code-centric approach.

Actually, I would've probably categorized Stripes as a Traditional MVC (but with lots of bells and whistles). I don't think it has the component development aspect that supports vertial development through the UI back to the model in a stateful manner.

I could be wrong (which is why I didn't bother to name frameworks in the post), but I'm almost thinking that wickett and tapestry would be considered hybrid, only because I assume that there's still a page object that supports component coordination, leaving a 1:1 relationship between java and views?

but I'm almost thinking that wickett and tapestry would be considered hybrid, only because I assume that there's still a page object that supports component coordination, leaving a 1:1 relationship between java and views?

Nah. I wouldn't agree to that. JSF has a view root, Wicket has a page object. The page provides the context that allows components to render themselves, like JSF's view root does and the toplevel containers of Swing do.

Wicket allows you to create your components totally independ of a page, and - useful when doing ajax - they can be rendered independently too.

but I'm almost thinking that wickett and tapestry would be considered hybrid, only because I assume that there's still a page object that supports component coordination, leaving a 1:1 relationship between java and views?

Nah. I wouldn't agree to that. JSF has a view root, Wicket has a page object. The page provides the context that allows components to render themselves, like JSF's view root does and the toplevel containers of Swing do.

The difference I was drawing upon though is that while the concepts of a root 'component' are the same, you are required to explicitly define them within wicket or tapestry, correct? JSF is more like a portal, you just drop them into the view and the 'page' concept is a reflection of it, not the other way around. The end result in these frameworks is the same, constituting the stateful components-- the only separation is the explicit page/action artifact required in development.

Keep in mind, I'm not pointing which solution is better (nor was that blog), there are many times when I wish there was a 'standard' page concept to JSF...

Wicket allows you to create your components totally independ of a page, and - useful when doing ajax - they can be rendered independently too.

I've been meaning to see how you guys coordinate that! Is it agnostic to the components-- meaning the components don't have to know that they are being processed with AJAX?

I've been meaning to see how you guys coordinate that! Is it agnostic to the components-- meaning the components don't have to know that they are being processed with AJAX?

There is a but... :) Those components still have to operate in a page context. But they can be rendered on themselves after that. It would be possible to completely decouple components, but that would introduce inefficiencies in how we solve back button support, clustering support, etc, you haven't done that till date. We haven't found enough reasons for it, as the page concept works fine.

JSF is more like a portal, you just drop them into the view and the 'page' concept is a reflection of it, not the other way around.

Speaking about dropping into the view (shameless plug follows): you can drop a Tab Component that is created with JSP Controls Tag Library into any JSP page and it will "just work" (c) ;-) All you need in the composite page is this:

  <div id="TabComponent">
    <jsp:include page="tabComponent.jsp"/>
  </div>

The component handles its own events and redraws itself, like a portlet.

the components don't have to know that they are being processed with AJAX?

To end with self-advertising (Eelco, Jonathan, hope you won't hate me for that): try the aforementioned Tab Component again. If Javascript is turned on, the component updates itself in-place using Ajax (AHAH, AJAH, whatever). Now turn Javascript off. Still works, no changes in user experience. This time it redirects to composite page, which in turn reloads itself and pulls up everything that is on it. Two-mode components, baby :-) Plain JSP, hammer and sickle, no hi-tech stuff.

And now I am shutting up :-)

I went to the URL you mentioned and yes, it's pretty impressive... However, I noticed by viewing the source, that div's and span's are sharing the same id attribute... That's not kosher for Javascript, is it? Is there a way to prevent your components from creating those duplicate id's?

I went to the URL you mentioned and yes, it's pretty impressive... However, I noticed by viewing the source, that div's and span's are sharing the same id attribute... That's not kosher for Javascript, is it? Is there a way to prevent your components from creating those duplicate id's?

This is has been fixed in version 0.4

(Eelco, Jonathan, hope you won't hate me for that)

Michael, we are full of love. I shed tears of joy seeing your participation here ;)

(Eelco, Jonathan, hope you won't hate me for that)

Michael, we are full of love. I shed tears of joy seeing your participation here ;)

:-) I just don't get why Michael doesn't join the darkside and work on contributing to component frameworks.

\but I'm almost thinking that wickett and tapestry would be considered hybrid, only because I assume that there's still a page object that supports component coordination, leaving a 1:1 relationship between java and views?

Ok, I re-read that. Yes, there is a 1:1 relationship between java and a view. How is that wrong though? It was a deliberate choice (simplicity) to do so. We discussed introducing renderers but decided not to go for that. If you want to render other kinds of markup, you have easy to use mechanisms for doing that; I'll end with an example. Furthermore, if you really want to do wild stuff, like creating XUL components, you just create a different component hierarchy. Which is a good idea anyway, as XUL elements are pretty different from HTML elements, and a common abstraction would just be the weak common dominator.

Anyway, for example, say you want to render an xml page:

public class XmlPage extends WebPage
{
public XmlPage()
{
add(new PersonsListView("persons", ComponentReferenceApplication.getPersons()));
}

public String getMarkupType()
{
return "xml";
}

private static final class PersonsListView extends ListView
{
public PersonsListView(String id, List list)
{
super(id, list);
}

protected void populateItem(ListItem item)
{
Person person = (Person)item.getModelObject();
item.add(new Label("firstName", person.getName()));
item.add(new Label("lastName", person.getLastName()));
}
}
}

XmlPage.xml:

<?xml version='1.0' encoding='utf-8'?>
<example>
<persons xmlns:wicket="http://wicket.sourceforge.net/">
<person wicket:id="persons">
<firstName><label wicket:id="firstName"></label></firstName>
<lastName><label wicket:id="lastName"></label></lastName>
</person>
</persons>
<explaination><![CDATA[
  You can use any XML based markup with Wicket. You want
  to do VoiceML, WML, whateverML? Please join us on our
  questee of creating a great framework!
]]>
</explaination>
</example>

You can differ the actual template that is being used by differing the markup type, just as you can differ the locale (XmlPage_nl.xml would automatically load the dutch template for instance) and something we call the variant. Of course, the component tree backing it is still largely static, but the models behind it are not and with panel swapping etc, you can do anything you can think off.

I think not having a seperate renderer doesn't make Wicket a non component based framework. Having renderers is a technique, not a goal in itself.

Ok, I re-read that. Yes, there is a 1:1 relationship between java and a view. How is that wrong though? It was a deliberate choice (simplicity) to do so. We discussed introducing renderers but decided not to go for that. If you want to render other kinds of markup, you have easy to use mechanisms for doing that; I'll end with an example. Furthermore, if you really want to do wild stuff, like creating XUL components, you just create a different component hierarchy. Which is a good idea anyway, as XUL elements are pretty different from HTML elements, and a common abstraction would just be the weak common dominator.

I know it was a deliberate choice with Wickett, I totally appreciate that fact, it's hella better than other frameworks ;-)

But renderers, aside, the only distiction I drew for hybrid vs. 'pure' component is that you can describe a page of components without additional artifacts such as a page or action counterpart as a requirement (the action is probably a bad choice of words for us). For some this is good, others it's not so good.

But renderers, aside, the only distiction I drew for hybrid vs. 'pure' component is that you can describe a page of components without additional artifacts such as a page or action counterpart as a requirement (the action is probably a bad choice of words for us). For some this is good, others it's not so good.

But you can. For instance a panel with Wicket is completely described on it's own, including it's markup. At runtime it needs to sit in a page to render, but that information doesn't have to exist when you are creating your component.

Maybe I'm not getting your point. And hey, no worries I'm not offended. Just like to agree on the terms we're using :)

but I'm almost thinking that wickett and tapestry would be considered hybrid, only because I assume that there's still a page object that supports component coordination, leaving a 1:1 relationship between java and views?

Nah. I wouldn't agree to that. JSF has a view root, Wicket has a page object. The page provides the context that allows components to render themselves, like JSF's view root does and the toplevel containers of Swing do.Wicket allows you to create your components totally independ of a page, and - useful when doing ajax - they can be rendered independently too.

Good idea, JSF + Ajax still is a tad tricky, but doable, you cannot route into the components directly but you have to provide a path to hook in the components seamlessly (usually over a servlet triggering the jsf phases or a phase listener where it is done)
In the end it is doable and done that you have an ajaxed component which from the programming side looks equal to one not ajaxed (aka model/controller binding via el and a backend model/controller)
But JSF has no clearly defined infrastructure for doing those things yet, 1.2 will become somewhat better but not perfect, guess that is a good place where frameworks like Shale can hook in to provide standard ways.

Does anybody have some good links discussing the merits of page based frameworks (struts, spring, webwork, asp) versus component based frameworks (wicket, tapestry, echo, jsf?, asp.net)?

I would not call Struts, Spring MVC or WebWork as page-based frameworks. Page-based frameworks are ASP, ASP.NET; less so JSF and Wicket because they support subviews/panels and promote their usage. Instead of working with pieces of Model that accept input and render themselves, these frameworks concentrate on the View, turning MVC into VCM. Which is not necessarily a bad thing.

To some, "page oriented" means that control logic is embedded in the mark-up file (e.g. JSP page). They distinguish this from the Struts approach, in which actions and a special servlet provide the control.

One can use the phrase "page-oriented" in a completely different sense, however. Traditional web frameworks are page-oriented in that the tag markup page refers to and makes calls upon the programming language code (whether via scripting, custom tags, or standard tag libraries). Adding subviews and panels, as in JSF, is merely a variation. Wicket HTML files, in contrast, make no reference to programming language code; rather, the code refers to markers in the HTML file. Wicket is therefore a _code-oriented framework_, rather than page- (or tagfile-) oriented.

Keeping business logic out of your mark-up files is good, but it's better to avoid embedding _any_ logic there -- not even presentation logic! Tag mark-up files are not object-oriented; working with any logic you put in them is like going back to the assembler-language days when your only tool of re-use was the macro definition.

In Wicket's code-oriented approach, tag-markup (i.e. HTML) is used only to let Java components know where to display themselves, and perhaps to add a bit of styling. The rest of the presentation logic is embedded within Java-language Wicket components; to re-use this logic the programmer has all the abstraction tools of object orientation at her disposal. _That_ is the Wicket advantage.

Does anybody have some good links discussing the merits of page based frameworks (struts, spring, webwork, asp) versus component based frameworks (wicket, tapestry, echo, jsf?, asp.net)?

While I don't mention/categorize specific frameworks, you can probably identify what kinds there are in this blog here:

http://weblogs.java.net/blog/jhook/archive/2006/03/extending_the_w.html

While I don't mention/categorize specific frameworks, you can probably identify what kinds there are in this blog here:http://weblogs.java.net/blog/jhook/archive/2006/03/extending_the_w.html

Nice article! Funny that you call those model 2 frameworks 'traditional mvc'. Don't let mr. Burbeck hear it ;)

While I don't mention/categorize specific frameworks, you can probably identify what kinds there are in this blog here:http://weblogs.java.net/blog/jhook/archive/2006/03/extending_the_w.html

Nice article! Funny that you call those model 2 frameworks 'traditional mvc'. Don't let mr. Burbeck hear it ;)

I would have used 'legacy model2 mvc' instead of 'traditional mvc'.

While I don't mention/categorize specific frameworks, you can probably identify what kinds there are in this blog here:http://weblogs.java.net/blog/jhook/archive/2006/03/extending_the_w.html

Nice article! Funny that you call those model 2 frameworks 'traditional mvc'. Don't let mr. Burbeck hear it ;)

I would have used 'legacy model2 mvc' instead of 'traditional mvc'.

that was my attempt at humor...

While I don't mention/categorize specific frameworks, you can probably identify what kinds there are in this blog here:http://weblogs.java.net/blog/jhook/archive/2006/03/extending_the_w.html

Nice article! Funny that you call those model 2 frameworks 'traditional mvc'. Don't let mr. Burbeck hear it ;)

I would have used 'legacy model2 mvc' instead of 'traditional mvc'.

that was my attempt at humor...

And a valiant attempt it was!

Does anybody have some good links discussing the merits of page based frameworks (struts, spring, webwork, asp) versus component based frameworks (wicket, tapestry, echo, jsf?, asp.net)?

Not by hand unfortunately. A few things why *I* like component based frameworks better:
* Better reuse. Don't only reuse the view, but also all interaction.
* Scales better for complexity. So you have this page with a paging list, some tabs and a form, and you decide to put the paging list on another page. A good component based framework has components that are self contained, thus they can be placed on any page, in any context etc. without you having to figure out how to pass those extra paremeters (e.g. page number) or cleanup session variables you might have used instead.
* Think in components/ objects instead of in request parameters etc. Proponents of model 2 frameworks (what you called page oriented frameworks) will say that they will stay closer to what the web actually is. My preference however is to get away from that mess and have a programming model that is more akin to a desktop application. SQL is more close to what you are doing if you work with databases, and it sure makes sense to directly use SQL sometimes, but in general I prefer to use Hibernate or JDO. To me, SQL vs ORM == model 2 vs CBD.
* The procedural character of model 2 frameworks freaks me out. I hate it, while I love everything else about programming with Java.

Totally my 2c :)

That is supposed to be simple:

If you are developing a web application with rich UI, then use component based framework which will save you from hard issues of managing state in a complex UI web app.

If you are developing a web site, the you'd better go with page based framework which will save you from the complexities of the component oriented web frameworks.

If you are developing a web application with rich UI, then use component based framework which will save you from hard issues of managing state in a complex UI web app. If you are developing a web site, the you'd better go with page based framework which will save you from the complexities of the component oriented web frameworks.

Thank you! I wish there were more guidance of this kind when discussing web frameworks. The idea that the different frameworks have suitability to different classes of applications is too often lost in the heated "best framework" debate.

However, I do not want my team to maintain skill sets in three frameworks to cover the range of web applications we build. And our system administrators to maintain server environments for three different frameworks.

An engineer will say "Use the best tool for the job". A boss will say "Use the popular framework that we have standardized on for all our projects".

Now the usual response would be to call the boss "pointy haired," but the more responsible and experienced among us will recognize the validity of trying to minimize the skill sets that must be maintained and server adminstration overhead and external dependencies.

What is desired is one framework that scales seamlessly (mind the pun) from content oriented websites to enterprise data entry applications.

Consider that some websites have a combination of requirements. The typical e-commerce site has a simple product catalog browsing segment that leads to a check-out/account-creation phase that involves more sophisticated component-oriented interactions. I don't want to use two separate frameworks for this scenario. I want a framework that scales. Simple stuff should be easy but more sophistated features should be available for when I need them.

So, for me, the question is, "which type of framework scales better?" Do action based frameworks like WebWork/Struts scale up to sophisticated component interactions better than JSF-based frameworks scale down to "content oriented" applications like database publishing, e.g., http://imdb.com ?

I would argue that in fact many MVC architectures are actually URL-based and are not even up to the page-based model. For example, in Struts you can end up coding classes for every URL in your app. That said, here's a few musings on the subject:

http://jroller.com/page/cardsharp?entry=components_components_components

http://jroller.com/page/cardsharp?entry=componentize_yourself

As long as we're talking about Wicket, could someone tell me I'm wrong about the following, because I've searched docs and examples without finding an answer.

Briefly, I want to display a List of POJOs. Here view.getUsers() returns a list of User objects.

In Java code:

add(new ListView("users", view.getUsers()) {
    public void populateItem(final ListItem p_item) {
        final User user = (User) p_item.getModelObject();
        p_item.add(new Label("username", user.getUsername()));
        p_item.add(new Label("password", user.getPassword()));
    }
});

And in HTML template:

<table>
  <tr wicket:id="users">
    <td><span wicket:id="username"></span></td>
    <td><span wicket:id="password"></span></td>
  </tr>
</table>

Two concerns/questions:

1. If I add a property to the User object, I have to add a line in the Java code and in the HTML template. This violates the DRY principle, doesn't it?

2. Can't I just bind the List of Users to something, like "users", in the Java code, and then in the template, iterate through the list and display what I want? E.g. in FreeMarker this would look like:

<table>
  <#list users as user>
    <tr>
      <td>${user.username}</td>
      <td>${user.password}</td>
    </tr>
  </#list>
</table>

Anything more or less equivalent in Wicket?

Thanks in advance for your help.
Frederic Daoud

Well, you can already embed VelocityPanels in Wicket. And it would be easy to make a FreemarkerPanel for this sort of thing (Freemarker is a pretty nice templating solution). But I'm quite certain that Wicket will never directly allow you to mix code into your template. Wicket is very strict about separating the model and controller (the Java component) from the view (the markup). This is an incredibly important thing and just as important as the DRY principle in creating UIs.

Also, please recognize that just because the code above repeats itself (debatable, but I can accept your criticism to some degree), doesn't mean that the Wicket *CORE* is to blame for that. Wicket is an extensible framework. The core is going to stay pretty small and simple. It is not meant to solve this problem. Probably the right thing to do for something like the above (if you really want to be DRY) is to create your own BeanPanel or view class or whatever which encapsulates repeating properties of objects (or editing of objects or whatever). You can definitely do this in Wicket and there is a start at a bean panel in wicket-sandbox. However, I don't think this will ever be part of the core (maybe wicket-extensions if someone has the time to finish the bean panel and support it). In other words, how you don't repeat yourself in Wicket is sometimes going to be pretty specific to your own requirements. I posted a few thoughts on this on my blog.

There is already an implementation of a FreeMarkerPanel in wicket-stuff cvs under wicket-contrib-freemarker. You should know that Jon :)

I had no idea. Seriously! I can't even keep up with all the stuff people are doing with Wicket anymore...

...is to create your own BeanPanel or view class or whatever which encapsulates repeating properties of objects (or editing of objects or whatever). You can definitely do this in Wicket and there is a start at a bean panel in wicket-sandbox. However, I don't think this will ever be part of the core (maybe wicket-extensions if someone has the time to finish the bean panel and support it).

Yeah. Such a generic bean panel is never done, and gets more complex from an API point of view when you want to support more use cases. But the current version basically prints out the properties of a bean, and has some javabean like extensions that allow you to provide custom panels for certain properties. It's usage is as easy as:

add(new BeanPanel("bean", myBean);

and

<span wicket:id="bean">[bean contents here]</span>

I'll probably move it to the examples project to give people an idea of how to tackle things like this.

This doesnt violate the DRY principal at all. In java you are declaring the component tree/data definition, while in markup you are defining presentation. While in your trivial example this seems like duplication it is not at all once you are building a real application where components are not always as simple as Labels.

Yeah. I agree. I was being very generous. I think you are correct. Also, if Wicket (just the current CORE) violates the DRY principle here, then so does pretty much every component framework out there (including Freemarker... why, after all, are you going to repeat that kind of loop in more than one HTML file? Hmmm?). To be truly and absolutely DRY, as I was pointing out, you want to encapsulate the whole idea of looping through objects and displaying/editing their properties in a general purpose, reusable object. This is absolutely doable in Wicket. It's just not something that belongs in core. It is not something that is easily encapsulated at all in something like Freemarker, which is not out-of-the-box reusable and therefore leads to a lot of repetition (I don't hate Freemarker, btw... I think there are good reasons to use it for specific focused problems).

I guess it doesn't violate DRY if you consider HTML your only presentation option. Thinking that way make a lot of sense these days. But for example, it wouldn't be impossible to write a Mozilla XUL peer (or maybe XAML in the future) for Echo2 widgets. In fact, there's a somewhat obscure sourceforge project that has that goal in mind, but I just can't remember it's name right now. Of course you could come up with an XML presentation abstraction and then use XSLT too.

But that's nothing new. Something like SWT already does exactly that. It uses win32 controls for the win platform, gtk+ widgets for X, and Carbon (I guess) for the Mac.

I say it does violate DRY, it's just for what most people are doing today on the web it just doesn't matter much.

I guess it doesn't violate DRY if you consider HTML your only presentation option. Thinking that way make a lot of sense these days. But for example, it wouldn't be impossible to write a Mozilla XUL peer (or maybe XAML in the future) for Echo2 widgets.

It's actually easy to do that with Wicket too; in fact I did write a couple of XUL widgets for fun some time ago. And there are people using it for XML too.

Wicket isn't violating the DRY principle at all. Most frameworks in fact don't violate this as they generally try to come up with solutions that keep you from doing that worst DRY offense: copy 'n paste your applications together.

While in your trivial example this seems like duplication it is not at all once you are building a real application where components are not always as simple as Labels.

*** warning - broad generalizations to follow ***

Java framework developers assume that the application developer needs control over EVERYTHING. Consequently, there's a lot of "apparent repitition" because 93.27% of the time application layers A, B, and C match, tranforming all that glorious mapping and control into annoying boilerplate code.

Ruby framework developers assume the application developer always wants A, B, and C to match, because thinking about multiple layers would simply be too boring. Metaprogramming is more fun.

---------------------------------------------

Why does it have to be an either or?

Why should a page designer be exposed to anything more than "wicket:id", (nothing but a custom attribute) easy to digest: <#list users as user> in spite of any DRY principle!? Wicket got it right, and if DRY is offended, ask DRY to take a hike.

Why should a page designer be exposed to anything more than "wicket:id", (nothing but a custom attribute) easy to digest: <#list users as user> in spite of any DRY principle!? Wicket got it right, and if DRY is offended, ask DRY to take a hike.

The markup below does not show relationship between "users", "username" and "password", while in fact this relationship exists and is used to build the table:

  <tr wicket:id="users">
    <td><span wicket:id="username"></span></td>
    <td><span wicket:id="password"></span></td>
  </tr>

A page designer must know this relationship. He must know that "username" and "password" are peers and together belong to "users" (by the way, why "users", not "user")? What will happen if one specifies "username" without putting "users" first? What will happen if one specifies "username" instead of "users" and vice versa?

Wicket IDs are easy on browser, making preview simple, but are they easy on developer? There is no keypath, that is, qualified name like "users.password". The more complex and larger the object, the larger the page, the less evident is the relationship between wicket IDs and real objects. You might say "This is just an ID, this is not an object property." Nope. These IDs are the part of the view-model simbiosis that should be known by page designer or by whoever is responsible for putting these IDs in HTML, otherwise the page would render junk.

On the other hand, I just realized that these IDs are just strings and can be called whatever one likes, for example "users.username". In this case the burden to properly name the properties would switch to a Java programmer.

The code below might seem "too JSP, yuck, yuck, run away!", but it does not requre Java object structure to follow HTML element structure. Instead, it shows the relationship between objects right there where they are used:

  <jsp:useBean id="user" class="UserData"/>
  <tr>
    <td>${user.username}</td>
    <td>${user.password}</td>
  </tr>

One glance at this markup and you can see what type of object is rendered and what are relationships between the dynamic elements. It may not be nice on preview, but why should one care about web designers more that about developers? Why web designers should be treated better that desktop app designers? For Windows app designer, resource editor is the primary tool. He is no Picasso, he is merely a tracer of another guy's work, who did it on canvas or in Photoshop at best. "Web designers" are not artists, they are user interface developers and as such should know some minimal programming stuff.

The markup below does not show relationship between "users", "username" and "password", while in fact this relationship exists and is used to build the table:

  <tr wicket:id="users">
    <td><span wicket:id="username"></span></td>
    <td><span wicket:id="password"></span></td>
  </tr>

This statement is simply not true. From the above piece of markup it is evident that component [username] and component [password] are peers, and are both children of component [users]. Wicket's component hierarchy in java code matches the hierarchy in the template.

<jsp:useBean id="user" class="UserData"/>
  <tr>
    <td>${user.username}</td>
    <td>${user.password}</td>
  </tr>

If a compound model is used ( as is often the case in wicket ) then component's id /is/ the property path. So if a compound property is used in the wicket sample above it will in fact translate to user.username and user.password just as it would in a jsp. True, maybe not as explicit to the designer working on the template, but explicit to the developer who would actually care about this.

Furthermore, this is only true for trivial cases where you are displaying simple properties. Say UserData has a compound Address property. If you want to use an include or any other kind of compound approach to recycle your address-view template, you will lose this obvious property semantic in any framework because it is abstracted by the compound view template.

All this DRY talk is really clouding the issue here. So I'm hereby launching a new programming practice called WET: Write Everything Twice. While this philosophy advocates writing everything twice, you are by no means constrained to stop there. Writing things three or four times can really show off your coding prowess. Doing so even more times can really drive the point home that you can *code*, baby!

So join me in this glorious revolution. I have seen the future and it is very, very WET.

All this DRY talk is really clouding the issue here. So I'm hereby launching a new programming practice called WET: Write Everything Twice. While this philosophy advocates writing everything twice, you are by no means constrained to stop there. Writing things three or four times can really show off your coding prowess. Doing so even more times can really drive the point home that you can *code*, baby!So join me in this glorious revolution. I have seen the future and it is very, very WET.

This is the funniest thing I've read all day. WET.

Would WET allow me to use XDoclet to help me write everything twice, thrice, etc.?

Does WET work with XDoclet 2 and Velocity to generate all of this code?

Thank you.

:o)

The code below might seem "too JSP, yuck, yuck, run away!", but it does not requre Java object structure to follow HTML element structure. Instead, it shows the relationship between objects right there where they are used:&nbsp;&nbsp;<jsp:useBean id="user" class="UserData"/> <tr> <td>${user.username}</td> <td>${user.password}</td> </tr>One

And sometimes that is nice to have. Actually we could things like that as we have a not-so-loudly advertised feature to create components on the fly with <wicket:component> tags. However, if people were to depend on that too much, the next thing they would want is the ability to embed links in that table, evaluate expressions to alternate the row classes, etc. We deliberately choose for the model where there is no page scripting, but everything that is dynamic is done in HTML.

It may not be nice on preview, but why should one care about web designers more that about developers? Why web designers should be treated better that desktop app designers?

Actually speaking for myself, I was attracted to Wicket as a programmer. I don't find page scriping attractive at all. Sometimes it is a lot faster - certainly for the easy stuff, and for some projects it might actually be a better choice to go with a framework that supports that. But I really like to program Java, make reusable components (to not violate the DRY principle... I want to reuse that address form for app x whenever, whereever I want without having to write one extra line of code or xml for it) and in general think in structures instead of procedures.

For Windows app designer, resource editor is the primary tool. He is no Picasso

Heh. Don't let em hear that ;), he is merely a tracer of another guy's work, who did it on canvas or in Photoshop at best. "Web designers" are not artists, they are user interface developers and as such should know some minimal programming stuff.I think we have seen different types then. I wasn't talking about 'failed programmers' (sorry for the sarcastic joke), but actually more the artistic type. In my experience they DO prefer clean templates and they do their jobs better when they can concentrate purely on HTML and CSS.

I dont see why the designer vs programmer argument always comes up. To me the advantage of having no script/logic in the markup is that I only have one place to look when something is not working. I dont have to check the logic in my java code, and then go off to check velocity/jsp/whatever logic in the template. When something doesnt work I know it is something in my java code.

Actually speaking for myself, I was attracted to Wicket as a programmer. I don't find page scriping attractive at all. Sometimes it is a lot faster - certainly for the easy stuff, and for some projects it might actually be a better choice to go with a framework that supports that. But I really like to program Java, make reusable components (to not violate the DRY principle... I want to reuse that address form for app x whenever, whereever I want without having to write one extra line of code or xml for it) and in general think in structures instead of procedures.

Right. But sometimes putting Java code inside a JSP page is not just scripting ;-) You can create and reuse JSP components pretty much the same as you can reuse Wicket components.

I wasn't talking about 'failed programmers' (sorry for the sarcastic joke), but actually more the artistic type. In my experience they DO prefer clean templates and they do their jobs better when they can concentrate purely on HTML and CSS.

So, your motto is no more knowledge than is needed to build aunt's "All my lovers" page? :-) I think that CSS and Javascript is a tremendously complex thing comparing to boring Java object references.

1. If I add a property to the User object, I have to add a line in the Java code and in the HTML template. This violates the DRY principle, doesn't it?

Where is the repeating part? In java you define your components and in HTML your tags. You only use components for tags that you want to apply dynamic behavior to.

Labels are kind of the worst example for Wicket code as - if everything in your application would be only labels - they have the least reason to be stateful. However, you can easily use things like e.g. a Velocity panel to display read-only code. Not that it's recommended to mix concepts though.

There's pro's and con's about Wicket - just as with any other framework I might say. I think the verbosity of this example is made good by the expressive power you get when you do more complex stuff. Think about how often components have to cooperate and/ or share their models. As you are in charge of creating the component structure, you can that any way you want, and it's generally much easier and strongly typed than a string based configuration file (or even annotations are usually pretty much string based) and/ or via some context object that let you introspect the component tree at runtime.

2. Can't I just bind the List of Users to something, like "users", in the Java code, and then in the template, iterate through the list and display what I want?

Like said, if you really want, you can use a freemarker or velocity panel. It would be relatively easy to even implement callbacks to that panel. But it's one of those things we decide not to do in favor of keeping things consistent.

For the sake of that consistency we decided to be rigid in our concepts. This means that we don't support 'scripting' like you proposed. The main reason for that is that we want to keep our templates clean, and we don't want to introduce any page/ component configuration other than with Java. That's something to get used to for a lot of people and some people end up liking it, while others don't. What you get in return are components that are truely self contained, which are relatively easy to create once you get used to working with plain Java again ( ;) ) and you won't have those messy templates again (or is that just me and my web designer friends hating that?).

Dear Wicket friends,

First, thank you kindly for taking the time to respond to my questions.

Second, folks, please don't think I mean any judgements, personal attacks, criticisms, etc. I was just asking a technical question, and I apologize if it sounded otherwise. I would never criticize an open-source framework. Besides, as long as there's Microsoft, I have no criticisms left for anything else ;-)

On the other hand, if I'm asking questions, it's simply because I'm interested in learning more about the project.

Now, the consensus seems to be that my example is not the "Wicket Way" of doing things in Wicket. I respect that. In fact, that was the reason for my post: obviously there's something wrong with the code I posted (I'm the first to admit that!), so what would be a better "Wicket Way"?

Perhaps it is to write a Wicket component in Java, which is responsible for the task of "displaying a list of users". Then, in the HTML template, this would simply appear as something like:

<span wicket:id="listOfUsers"></span>

This could be rendered as an HTML table, as in my example.

Now that would be cool. Now, in your HTML templates, if you need to display the list of users, just drop in that simple tag. Simple and reusable! Also, I can certainly appreciate the advantages of doing "more work in Java, less in the template".

Could you give me an idea of what the Java code for such a Wicket component would look like?

I'm going to stop here, in case I write something incorrect given that I'm just starting out with Wicket. I'd rather let the Wicket experts, who know what they are talking about, share their thoughts on this.

Thanks again for your help!
Frederic Daoud

Second, folks, please don't think I mean any judgements, personal attacks, criticisms, etc. I was just asking a technical question, and I apologize if it sounded otherwise.

No, you didn't come accross badly in any way. Certainly not for an open forum like this ;)

Now, the consensus seems to be that my example is not the "Wicket Way" of doing things in Wicket.

There's nothing wrong with your example. It could be written in sligthly less code by using compoundproperty models, but the advantage of your example is that any refactoring will go with it.

The part we didn't agree on, was that the DRY principle is violated in the first place, and that scripting (putting logic in your template) would be better. Sometimes the latter is more convenient, sometimes not. We choose to go for one philosphy, and while there are some break outs, we generally prefer that things are done in a uniform way. In other words, in this case we *did not* go for a trade-off.

Then, in the HTML template, this would simply appear as something like:

<span wicket:id="listOfUsers"></span>

This could be rendered as an HTML table, as in my example.Now that would be cool. Now, in your HTML templates, if you need to display the list of users, just drop in that simple tag. Simple and reusable! Also, I can certainly appreciate the advantages of doing "more work in Java, less in the template".Could you give me an idea of what the Java code for such a Wicket component would look like?

Sure. Java code:

public class UsersPanel extends Panel {

  public UsersPanel(String id, List users) {
    super(id);
    add(new ListView("users", users) {
       public void populateItem(final ListItem p_item) {
         final User user = (User) p_item.getModelObject();
         p_item.add(new Label("username", user.getUsername()));
         p_item.add(new Label("password", user.getPassword()));
    }});
  }
}

Html:

<wicket:panel>
  <table>
    <tr wicket:id="users">
      <td><span wicket:id="username"></span></td>
      <td><span wicket:id="password"></span></td>
    </tr>
  </table>
</wicket:panel>

That's for your reusable panel, which you can now use anywhere like:

add(new UsersPanel("users", users);

and:

<span wicket:id="users">[users here]</span>

or for previewability:

<span wicket:id="users">
  <wicket:remove>
  <table>
    <tr>
      <td>mini</td>
      <td>maxi</td>
    </tr>
  </table>
  <wicket:remove>
</span>

Eelco,

Thanks very much for your very informative, clear -- and prompt! -- reply.

Now that makes a whole lot of sense to me.

I appreciate your help,

Frederic

I kind of agree with Frederic - seems like wiket could use a little reflection to reduce the amount of controller code:

Something like:

add(new ListView("users", view.getUsers()) {});

ListView (or whatever Wicket class does the work) should be smart enough to translate
<span wicket:id="userName">

into

Object.getUserName


I could see in some cases wanting to add the specific Label instances in the case where you wanted to concatenate or provide data that is non-reflectable (is that a word)?

p_item.add(new Label("fullname", user.getFirstName() + " " _ user.getLastName()));

I kind of agree with Frederic - seems like wiket could use a little reflection to reduce the amount of controller code

We have that support in the form of CompoundPropertyModels.

I think it'd be great if Wicket could also jump on the EL-API. I fully realize that other expression languages allow method invocation/etc... but for things like defining event handlers, flexible variable and property resolution, a standard API, and the ability to produce other implementations of the EL-API that are within the same capacity of JEXL or OGNL-- you really can't go wrong!

I think it'd be great if Wicket could also jump on the EL-API. I fully realize that other expression languages allow method invocation/etc... but for things like defining event handlers, flexible variable and property resolution, a standard API, and the ability to produce other implementations of the EL-API that are within the same capacity of JEXL or OGNL-- you really can't go wrong!

If there is a clear advantage to supporting EL directly, it is something to consider. However, in Wicket 1.2. we replaced OGNL by our own simplified but optimized implementation (just simple property navigation). By doing that, we got rid of one of the last performance bottlenecks we had. Any idea on how well EL performs compared to OGNL?

I think it'd be great if Wicket could also jump on the EL-API. I fully realize that other expression languages allow method invocation/etc... but for things like defining event handlers, flexible variable and property resolution, a standard API, and the ability to produce other implementations of the EL-API that are within the same capacity of JEXL or OGNL-- you really can't go wrong!

If there is a clear advantage to supporting EL directly, it is something to consider. However, in Wicket 1.2. we replaced OGNL by our own simplified but optimized implementation (just simple property navigation). By doing that, we got rid of one of the last performance bottlenecks we had. Any idea on how well EL performs compared to OGNL?

Couldn't tell you. I'd be interested myself. It's publically available within the tomcat 6 work on SVN. Maybe a slight example might be that for moving from JSP to Facelets with JSF, there was a pure 15% increase in performance. Now, I can't necessarily attribute that number to Facelets or it's use of the new EL. But, no one complained about JSP performance in the first place. Also, the EL is optimized for serialization (for obvious reasons).

The 'geeky' stuff in the new EL:

http://weblogs.java.net/blog/jhook/archive/2006/03/the_unified_el.html

It's just I or another person didn't find a real simplicity in Wicket?

Well, luckily I have some ideas for turning our BeanPanel class into something really neat...

How would this be?

Code:

   add(new BeanPanel("users", users))

Markup:

   <span wicket:id="users"></span>

Simple enough for you?

To help you people realize how carried away you have got with this kind of stuff, read http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12

I think freedom of choice is a good thing but now, more than chaos, you've got Bizantium all over again. Get your act together: choose two frameworks (whichever), throw the others, and forget the past. Don't you see the barbarians are already up the walls?

To help you people realize how carried away you have got with this kind of stuff, read http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12 I think freedom of choice is a good thing but now, more than chaos, you've got Bizantium all over again. Get your act together: choose two frameworks (whichever), throw the others, and forget the past. Don't you see the barbarians are already up the walls?

That city got sacked by mistake by a different flavor of the same tribe. The 'barbarians' were amuzed, waited a couple of years and took over. Not sure where the link is :)

Joel is a great writer alright. Don't take anything you read literaly though. I'm sure some people feel great using only JSP, plain SQL, and XML streams. But I am glad to have frameworks *to choose from* and the freedom to not use them just the same. My first java web application was done with servlets doing print statements. I'm glad other frameworks build on top of that and got us to the point of today where we are able to build fairly sophisticated web applications that *are* maintainable.

I'm not against frameworks, in fact I'm all for a set of patterns and classes that make me more productive. The problem is that having too many choices, many of which are just variants of the same idea and several others just short lived experiments, don't show creativity but lack of leadership. Don't you see you're drowning programming teams in framework-choice paralysis?

I'm not against frameworks, in fact I'm all for a set of patterns and classes that make me more productive. The problem is that having too many choices, many of which are just variants of the same idea and several others just short lived experiments, don't show creativity but lack of leadership. Don't you see you're drowning programming teams in framework-choice paralysis?

Yeah. Agreed on what you outline as a lot of crap amongst those frameworks. But hey, it's open source, so your choice making process helped by a lot of transparency!

For all you people suffering from that modern world irritation with having too much choice (there's democracy, free trade, too many tv channels too) here's one way to select your frameworks:
1) Define an area where you have a problem or feel you can improve your development process. Don't fix a problem you don't have.
2) See what kind of frameworks you need based on 1), and decide - after a quick scan of the available frameworks - whether you want to go for all compassing frameworks or a combination of best of breed.
3) Use your favorite search engine to track down the most popular alternatives. If you came up with 50 *viable* alternatives, you are not a very efficient searcher and you will suffer from information overload paralysis within a few years. If you didn't you probably came up with less than ten as you just looked at the first two pages, and consulted some 'expert' sites or blogs for the popular choices.
4) Visit their websites, look at some idicators like how long they exist, mailing list activity, number of contributors and read some basic documentation to get a feeling for why the authors think their framework will help you.
5) Do a checkout of their code. Look at the quality of their code. See if there is sufficient testing code, look at the tests to see how things are done and whether corner cases you might expect are being tested. Besides giving you a good indication about the quality of the framework, it is just fun to look and learn from other people's code - at least when it is well written. And don't forget to check out any examples too.
6) Finally, pick your favorite two or three and, starting with your nbr one, create a simple prototype that displays just enough to 'prove' it will solve your problem.
x) If you didn't find any suitable framework, not to worry. At least you tried to prevent reinventing the wheel, and you probably got some inspiration on how you can start solving it yourself.
x) Don't adopt the decision making process of your manager. He has nothing else to do anyway, so he is specialized on formalizing his decisions based on common sense parameters (did anyone out here read freak economics?). You otoh have some code to write.
xx) Sometimes you make a bad choice. One of the hardest things to do is admit that and start over again. I am still sorry for the times I didn't and got stuck with a lousy framework.

So, yeah, it's some work. You spend a few days upfront for that multi-K project to select the best tools for the job. Of course, you don't *have* to do such a framework selection at the start of your project. Though I think it is a good idea for you and your boss, and personally I even like to go out and see what other people came up with :)

choose two frameworks (whichever), throw the others, and forget the past.

Which ones? ;-)

choose two frameworks (whichever), throw the others, and forget the past.

Which ones? ;-)

If I had to pick two frameworks, JSF (with Facelets plugin) and Spring.

If I couldn't use JSF (not allowed for some reason), I'd try to use Tapestry.

If I couldn't use Tapestry (not allowed for some reason), I'd look into Wicket or Echo.

If I couldn't use Wicket or Echo, I'd look into WebWork.

If I couldn't use WebWork, I'd use Spring MVC. (I like Spring MVC.)

Which ones? ;-)

OT, but I enjoyed jBPM and XFire a lot. They really helped me cut down development time and improve quality.

choose two frameworks (whichever), throw the others, and forget the past.

Which ones? ;-)

If I had to pick two frameworks, JSF (with Facelets plugin) and Spring.If I couldn't use JSF (not allowed for some reason), I'd try to use Tapestry.If I couldn't use Tapestry (not allowed for some reason), I'd look into Wicket or Echo.If I couldn't use Wicket or Echo, I'd look into WebWork.If I couldn't use WebWork, I'd use Spring MVC. (I like Spring MVC.)

choose two frameworks (whichever), throw the others, and forget the past.

Which ones? ;-)

If I had to pick two frameworks, JSF (with Facelets plugin) and Spring.If I couldn't use JSF (not allowed for some reason), I'd try to use Tapestry.If I couldn't use Tapestry (not allowed for some reason), I'd look into Wicket or Echo.If I couldn't use Wicket or Echo, I'd look into WebWork.If I couldn't use WebWork, I'd use Spring MVC. (I like Spring MVC.)

Rick, your post makes it seem like you are choosing a framework without any consideration for the class of application you are developing. From previous posts, it is evident that you do a lot of CRUD intensive internal corporate-type applications. Hence your choice of a component-based framework is understandable.

It would be interesting to know if JSF/Facelets would still be your 1st choice if you were tasked with a website like http://imdb.com .

Rick, which

By the way, have everyone seen that: http://labs.openlaszlo.org/ "OpenLaszlo programs are written in XML and JavaScript and transparently compiled to Flash and soon (strike that - M.J.) *now* DHTML." Things are getting more interesting!

choose two frameworks (whichever), throw the others, and forget the past.

Which ones? ;-)

If I had to pick two frameworks, JSF (with Facelets plugin) and Spring.If I couldn't use JSF (not allowed for some reason), I'd try to use Tapestry.If I couldn't use Tapestry (not allowed for some reason), I'd look into Wicket or Echo.If I couldn't use Wicket or Echo, I'd look into WebWork.If I couldn't use WebWork, I'd use Spring MVC. (I like Spring MVC.)

Rick, your post makes it seem like you are choosing a framework without any consideration for the class of application you are developing. From previous posts, it is evident that you do a lot of CRUD intensive internal corporate-type applications. Hence your choice of a component-based framework is understandable.It would be interesting to know if JSF/Facelets would still be your 1st choice if you were tasked with a website like http://imdb.com

If I were tasked with a site like that, I would probably use a CMS system to actually publish static pages-- but use a rich component framework to control the publishing/content on the web ;-) But, if you need some dynamic aspect to relatively static content, I would probably go with Struts, only because theres such a large base of well-documented knowledge around it.

If I were tasked with a site like that, I would probably use a CMS system to actually publish static pages-- but use a rich component framework to control the publishing/content on the web ;-) But, if you need some dynamic aspect to relatively static content, I would probably go with Struts, only because theres such a large base of well-documented knowledge around it.

That makes sense. Thank you for this well-reasoned reply. It is refreshing to see a framework expert recommend something other than the framework they are involved with.

I'm hoping to have my team standardize on a single framework that scales the full spectrum of web applications, from simple product catalog browsing to sophisticated data entry intensive apps -- perhaps an action based framework that allows for a smooth transition to using JSF components where appropriate. Perhaps Struts is a good choice.

choose two frameworks (whichever), throw the others, and forget the past.

Which ones? ;-)

If I had to pick two frameworks, JSF (with Facelets plugin) and Spring.If I couldn't use JSF (not allowed for some reason), I'd try to use Tapestry.If I couldn't use Tapestry (not allowed for some reason), I'd look into Wicket or Echo.If I couldn't use Wicket or Echo, I'd look into WebWork.If I couldn't use WebWork, I'd use Spring MVC. (I like Spring MVC.)

Rick, your post makes it seem like you are choosing a framework without any consideration for the class of application you are developing. From previous posts, it is evident that you do a lot of CRUD intensive internal corporate-type applications. Hence your choice of a component-based framework is understandable.It would be interesting to know if JSF/Facelets would still be your 1st choice if you were tasked with a website like http://imdb.com

If I were tasked with a site like that, I would probably use a CMS system to actually publish static pages-- but use a rich component framework to control the publishing/content on the web ;-) But, if you need some dynamic aspect to relatively static content, I would probably go with Struts, only because theres such a large base of well-documented knowledge around it.

Same as Jacob except substitute WebWork or Spring MVC instead of Struts (eventhough I have a lot of experience with Struts). (I have more experience with Spring MVC ... more than WebWork).

choose two frameworks (whichever), throw the others, and forget the past.

Which ones? ;-)

If I had to pick two frameworks, JSF (with Facelets plugin) and Spring.If I couldn't use JSF (not allowed for some reason), I'd try to use Tapestry.If I couldn't use Tapestry (not allowed for some reason), I'd look into Wicket or Echo.If I couldn't use Wicket or Echo, I'd look into WebWork.If I couldn't use WebWork, I'd use Spring MVC. (I like Spring MVC.)

Rick, your post makes it seem like you are choosing a framework without any consideration for the class of application you are developing. From previous posts, it is evident that you do a lot of CRUD intensive internal corporate-type applications. Hence your choice of a component-based framework is understandable.It would be interesting to know if JSF/Facelets would still be your 1st choice if you were tasked with a website like http://imdb.com

If I were tasked with a site like that, I would probably use a CMS system to actually publish static pages-- but use a rich component framework to control the publishing/content on the web ;-) But, if you need some dynamic aspect to relatively static content, I would probably go with Struts, only because theres such a large base of well-documented knowledge around it.

Same as Jacob except substitute WebWork or Spring MVC instead of Struts (eventhough I have a lot of experience with Struts). (I have more experience with Spring MVC ... more than WebWork).

Oh, I wouldn't use any of those model 2/ web mvc frameworks. JSP got much better the last few versions, and there are nice sets of taglibs that will be helpful. A site like that - if for some reason I couldn't use Wicket for it - I would just go for model 1 JSP. I agree with Michael on this. *Maybe* I would give Rife or Stripes a look, or just consider Ruby. Anything but model 2. I'm totally done with those.

A site like that - if for some reason I couldn't use Wicket for it - I would just go for model 1 JSP. I agree with Michael on this. *Maybe* I would give Rife or Stripes a look, or just consider Ruby. Anything but model 2. I'm totally done with those.

I forgot about Tapestry. I would be ready to give that another try too.

A site like that - if for some reason I couldn't use Wicket for it - I would just go for model 1 JSP. I agree with Michael on this. *Maybe* I would give Rife or Stripes a look, or just consider Ruby. Anything but model 2. I'm totally done with those.

I forgot about Tapestry. I would be ready to give that another try too.

Just a comment: is it me or has Tapestry lost some of its shine lately? I dunno if it's due to JSF uprising or to similar but simpler frameworks competition, but anyway, one year ago almost everybody would be jumping around shouting "Tapestry!" as the only viable answer besides Struts to all our web apps issues...
PS: I know this looks like a flame bait, but I assure you it is not! It's nice to find such a high level discussion regarding this touchy subject without degenerating into "mine is bigger than yours" fights... ;)

A site like that - if for some reason I couldn't use Wicket for it - I would just go for model 1 JSP.

So your 1st choice would be to use Wicket, a component-based framework, to build a database publishing site like http://imdb.com ?

That's interesting, because when I look at a site like that I don't see components, at least not what I usually think of as components - form controls, tree control, etc. I usually think of component-oriented frameworks as being best for form-intensive applications, such as internal enterprise data entry applications. Perhaps I need to rethink what a component actually is.

So your 1st choice would be to use Wicket, a component-based framework, to build a database publishing site like http://imdb.com ? That's interesting, because when I look at a site like that I don't see components, at least not what I usually think of as components - form controls, tree control, etc. I usually think of component-oriented frameworks as being best for form-intensive applications, such as internal enterprise data entry applications. Perhaps I need to rethink what a component actually is.

Oooow, I see lot's and lot's of components! I see nested tabs, panels, lists (with panels) and more. When I look at that page, my natural reacion is to draw imaginary boxes around all that blocks and I see self contained components everywhere. Things like the blocks on the front page 'born today', 'upcomming this week', the search forms, 'quote of the day', the poll question, etc, etc. All neat little things that can be (and should be) developed completely independent of the rest of the page so that they can be put in any page you like afterwards, with or without ajax without a consequence.

As these pages are largely read-only, it wouldn't be too difficult with other frameworks either. In fact, using model 1 would be easy, and using a model 2 framework wouldn't have any advantages for this site imo. But using Wicket for this site wouldn't slow me down at all now that I 'unlearned' (HLS tm) scripting and model 2, and in general I enjoy working with Java directly much more than I do working with JSPs etc. And as component based frameworks scale well for development, I wouldn't be afraid that, if there would be a need to put in trees, pageable list, multiple forms with result panels on the same page etc, the development effort would get unmanageable.

As yet another alternative, you might consider portlets for this site.

Oooow, I see lot's and lot's of components! I see nested tabs, panels, lists (with panels) and more. When I look at that page, my natural reacion is to draw imaginary boxes around all that blocks and I see self contained components everywhere. Things like the blocks on the front page 'born today', 'upcomming this week', the search forms, 'quote of the day', the poll question, etc, etc. All neat little things that can be (and should be) developed completely independent of the rest of the page so that they can be put in any page you like afterwards, with or without ajax without a consequence.As these pages are largely read-only, it wouldn't be too difficult with other frameworks either. In fact, using model 1 would be easy, and using a model 2 framework wouldn't have any advantages for this site imo. But using Wicket for this site wouldn't slow me down at all now that I 'unlearned' (HLS tm) scripting and model 2, and in general I enjoy working with Java directly much more than I do working with JSPs etc. And as component based frameworks scale well for development, I wouldn't be afraid that, if there would be a need to put in trees, pageable list, multiple forms with result panels on the same page etc, the development effort would get unmanageable.As yet another alternative, you might consider portlets for this site.

Thanks Eelco, your post helps me a lot.

I'm looking for a framework that has a broad sweet spot -- one that makes read-only sites easy but scales up well to more sophisticated UI interaction. I'd be hesitant to start with Model 1 JSP pages only to have this approach break down as the site starts requiring more sophisticated UI interaction. I want a framework that will scale as my site evolves. Sometimes sites have mixed UI requirements -- a read-only product catalog leading to a check-out phase -- I want a framework that is equally adept at both. I want a single framework that my team can standardize on for all of its web-app projects.

Your post makes me realize that I've underestimated the applicability of components. I'll now give greater consideration to Wicket, Tapestry, and JSF-based frameworks.

To the JSF experts: are there approaches you can recommend that would help JSF scale down to the read-only parts of a website, e.g., drilling down through a product catalog, without being overly cumbersome?

To the JSF experts: are there approaches you can recommend that would help JSF scale down to the read-only parts of a website, e.g., drilling down through a product catalog, without being overly cumbersome?

I'm not a JSF expert, but I think you can start out doing model 1 and decide to add JSF to that later.Personally, I don't like mixing concepts too much, but it would sure be a pragmatic approach.

I want a single framework that my team can standardize on for all of its web-app projects.

Having a universal framework is not like having a pen, which is also a clock. It more like having a car, which is also a ship and sometimes even a plane. Such cars do exist, but either they drive bad, or sail bad, or just simply look bad. And if they are able to soar above the pavement they fly like a brick. That is, mostly down.

On the other hand, automotive engineers don't have an option of building a car factory or a car factory factory, right while you driving.

I want a single framework that my team can standardize on for all of its web-app projects.

Having a universal framework is not like having a pen, which is also a clock. It more like having a car, which is also a ship and sometimes even a plane. Such cars do exist, but either they drive bad, or sail bad, or just simply look bad. And if they are able to soar above the pavement they fly like a brick. That is, mostly down. On the other hand, automotive engineers don't have an option of building a car factory or a car factory factory, right while you driving.

Michael, you surely must realize there are real costs in using the most specialized tool for each task.

In my Kitchen, I don't want a Cuisinart for dicing potatoes, a Mini-Cuisinart for chopping nuts, a pairing knife for slicing radishes, a garlic press for smashing garlic, etc. I don't have room in my kitchen for all that. And I don't want to clean it all after dinner.

Just give me a chef's knife and a cutting board and I can cook more efficiently.

It's anlogous to a "working set" in operating system theory. There are only so many skills that a team can be effective at before they start thrashing.

It's hard to argue with "Use the right tool for the job" but is it not unreasonable to demand:

(1) Tools with broad sweet spots -- tools that work efficiently across a wide range of applicability.

(2) A coherent set of tools that provide smooth migration paths between themselves. E.g., starting with Model 1 JSP and incorporating JSF as warranted by more sophisticated UI requirements.

Granted, such tools take greater skill to develop and even involve political factors. But with the talent and innovation present within the Java EE framework space, I think such tools should be achievable.

-- Allen

In my Kitchen, I don't want a Cuisinart for dicing potatoes, a Mini-Cuisinart for chopping nuts, a pairing knife for slicing radishes, a garlic press for smashing garlic, etc. I don't have room in my kitchen for all that. And I don't want to clean it all after dinner.

Just give me a chef's knife and a cutting board and I can cook more efficiently.

Depends on whether you are chef in a fancy restaurant or an army cook. If you have to feed a platoon you either need a machine for peeling/dicing/smashing potatoes, or a dozen of knives and a dozen of privates. The latter is a more likely choice. I don't know whether finding and recruiting consultants to write web pages is as simple as sending some soldiers to the Kitchen to chop nuts ;)

I don't know whether finding and recruiting consultants to write web pages is as simple as sending some soldiers to the Kitchen to chop nuts ;)

And I don't know why the consensus seem to be that programmers never want to learn new stuff or mess up when they do. I thought the consensus - at least amongst programmers - was that programmers were a smart bunch of driven by curiousity and creativity :)

I don't know whether finding and recruiting consultants to write web pages is as simple as sending some soldiers to the Kitchen to chop nuts ;)

And I don't know why the consensus seem to be that programmers never want to learn new stuff or mess up when they do. I thought the consensus - at least amongst programmers - was that programmers were a smart bunch of driven by curiousity and creativity :)

I think Java developers have every right to be frustrated with the amount of choice/diversity in the framework space (MVC is only one). That's why I've been finding test driven development to be the most ideal situation for developers-- only because it forces you to peel your code away from a particular framework methodology and you end up with extremely reusable code as the foundation of your 'domain model'. I guess in some sense, that's why I appreciate component frameworks, more particularly JSF, because you aren't tied to the request paradigm and the UI artifacts actually operate on your model instead of requiring you to operate on the framework.

-- Not Jacob

And I don't know why the consensus seem to be that programmers never want to learn new stuff or mess up when they do. I thought the consensus - at least amongst programmers - was that programmers were a smart bunch of driven by curiousity and creativity :)

It seems to me that the programmer community divides into two camps. The most valuable are exactly as you describe. But in my experience there are a lot of people to whom it is "just a job" and as such have little passion for learning and creativity on the job.

-Tim Fennell
Stripes: Because web development should just be easier

I want a single framework that my team can standardize on for all of its web-app projects.

Having a universal framework is not like having a pen, which is also a clock. It more like having a car, which is also a ship and sometimes even a plane. Such cars do exist, but either they drive bad, or sail bad, or just simply look bad. And if they are able to soar above the pavement they fly like a brick. That is, mostly down. On the other hand, automotive engineers don't have an option of building a car factory or a car factory factory, right while you driving.

Michael, you surely must realize there are real costs in using the most specialized tool for each task.In my Kitchen, I don't want a Cuisinart for dicing potatoes, a Mini-Cuisinart for chopping nuts, a pairing knife for slicing radishes, a garlic press for smashing garlic, etc. I don't have room in my kitchen for all that. And I don't want to clean it all after dinner.Just give me a chef's knife and a cutting board and I can cook more efficiently.It's anlogous to a "working set" in operating system theory. There are only so many skills that a team can be effective at before they start thrashing.It's hard to argue with "Use the right tool for the job" but is it not unreasonable to demand:(1) Tools with broad sweet spots -- tools that work efficiently across a wide range of applicability.(2) A coherent set of tools that provide smooth migration paths between themselves. E.g., starting with Model 1 JSP and incorporating JSF as warranted by more sophisticated UI requirements.Granted, such tools take greater skill to develop and even involve political factors. But with the talent and innovation present within the Java EE framework space, I think such tools should be achievable.-- Allen

Just depends. If your project is large is you have a great influx of people entering and leaving the project, use something standard/ popular. If your project is large but you work with a steady team on it, pick the best tools you can find. If your project is small, use what you have been using. Or - long term vision - if your project is small, and you have good programmers in your team, use the project to investigate new frameworks/ API's/ languages.

My 2c

To the JSF experts: are there approaches you can recommend that would help JSF scale down to the read-only parts of a website, e.g., drilling down through a product catalog, without being overly cumbersome?

I was going to reply to your question at Matt's blog, but I have too much respect for the guy to get into a competetive discussion with others there :-)

To answer this question, I'll reflect on some personal example of an action-based application that I recently worked on.

For all 'get' interactions, there was basically a 1:1 mapping between actions and views. product.do?id=34232 only ever goes to one page. Really, I could've just requested the view directly since there was no other view to associate. Security and Error handling were handled globally, so again, my execute method on the action basically just did 1 or 2 things and then forwarded to the one 'success' view. While having that 'execute' method does allow me to initialize my data up front, it's not really necessary. Much of the stuff ended up getting lazy loaded based on user permissions or current criteria (which avoided pushing stuff to the view needlessly).

In hindsight, I could've just gotten away with a simple backing bean that had the parameters from the URL auto assigned. Well, you can do that with JSF, independent of any UIComponents in the view. So now you've optionally removed the stateful UIComponent overhead, but still retained JSF's flexible EL/pluggable IoC model with your pages. Components that I did need in the UI to support rendering could be marked transient and not needed to be saved in session or serialized w/ overhead.

While I believe this answers your question, JSF will always have more overhead, even slimmed down, than something like Struts or WebWork. But maybe the point we're hitting on is that you can more easily scale up. The decision then comes down to hardware and number of concurrent users. I have heard of very large JSF applications being deployed on clusters, but if you only have a couple boxes to support thousands of concurrent users, you may want to start load testing early.

The best advice I can give to programmers is to delegate as much as possible to testable, framework agnostic objects. Then if you use a component framework or an action or hybrid framework, integration isn't that big of a deal. I laugh when I hear about Struts users that put their whole business model into Struts actions and then commit all of their time to figuring out how to expose their Struts code to other systems.

-- Not Jacob

I'll reflect on some personal example of an action-based application that I recently worked on.For all 'get' interactions, there was basically a 1:1 mapping between actions and views. product.do?id=34232 only ever goes to one page. Really, I could've just requested the view directly since there was no other view to associate.

What does this view do? Is it an edit form or read-only view? Does this app have a separate action to delete a product or to create a new one? This 1:1 relationship can be easily changed to 1:M having only two actions (or even one if you prefer), infinite number of commands and infinite number of views. Like modifyProduct.do?event=delete&id=34232 or renderProduct.do?mode=readonly&id=34232 or even renderProductInCurrentState.do?id=34232.

I laugh when I hear about Struts users that put their whole business model into Struts actions and then commit all of their time to figuring out how to expose their Struts code to other systems.

Not all Struts apps are written like this ;)

To the JSF experts: are there approaches you can recommend that would help JSF scale down to the read-only parts of a website, e.g., drilling down through a product catalog, without being overly cumbersome?

I was going to reply to your question at Matt's blog, but I have too much respect for the guy to get into a competetive discussion with others there :-)To answer this question, I'll reflect on some personal example of an action-based application that I recently worked on.For all 'get' interactions, there was basically a 1:1 mapping between actions and views. product.do?id=34232 only ever goes to one page. Really, I could've just requested the view directly since there was no other view to associate. Security and Error handling were handled globally, so again, my execute method on the action basically just did 1 or 2 things and then forwarded to the one 'success' view. While having that 'execute' method does allow me to initialize my data up front, it's not really necessary. Much of the stuff ended up getting lazy loaded based on user permissions or current criteria (which avoided pushing stuff to the view needlessly).In hindsight, I could've just gotten away with a simple backing bean that had the parameters from the URL auto assigned. Well, you can do that with JSF, independent of any UIComponents in the view. So now you've optionally removed the stateful UIComponent overhead, but still retained JSF's flexible EL/pluggable IoC model with your pages. Components that I did need in the UI to support rendering could be marked transient and not needed to be saved in session or serialized w/ overhead.While I believe this answers your question, JSF will always have more overhead, even slimmed down, than something like Struts or WebWork. But maybe the point we're hitting on is that you can more easily scale up. The decision then comes down to hardware and number of concurrent users. I have heard of very large JSF applications being deployed on clusters, but if you only have a couple boxes to support thousands of concurrent users, you may want to start load testing early.The best advice I can give to programmers is to delegate as much as possible to testable, framework agnostic objects. Then if you use a component framework or an action or hybrid framework, integration isn't that big of a deal. I laugh when I hear about Struts users that put their whole business model into Struts actions and then commit all of their time to figuring out how to expose their Struts code to other systems.-- Not Jacob

Thanks Jacob, that helps my understanding a great deal.

I'm willing to incur a performance overhead hit if that's the price of using a framework that can scale up and down the full spectrum of my projects' UI requirements. I'm more concerned with development overhead than performance overhead.

Your point about "delegating as much as possible to testable, framework agnostic objects" is well taken.

Indeed, that ties nicely into the pragmatic approach Eelco suggested: use Model 1 JSP where it suffices and introduce JSF components as UI requirements scale up. If application logic is contained in framework agnostic objects then this approach should provide a smooth transition path. This might be more practical than my quest for a single full-spectrum uber framework.

Conceivably then, a typical e-commerce site could have its product catalog browsing phase built with Model 1 JSP and a seamless transition to JSF for the more intricate UI interactions of the account-creation/check-out phase. Does this sound like a good approach?

Allen

P.S. Why do you sign your post "Not Jacob"?

Conceivably then, a typical e-commerce site could have its product catalog browsing phase built with Model 1 JSP and a seamless transition to JSF for the more intricate UI interactions of the account-creation/check-out phase. Does this sound like a good approach?

Yes. You can do a series of light weight pages that are supported by page beans-- so it's still a good idea to put your logic elsewhere. But when you need more complex interactions... such as viewing a cart w/ quick item entry, validation, multiple updates, sorting, paging, transactions, ajax, etc-- then have you instead link to 'cart.jsf'.

P.S. Why do you sign your post "Not Jacob"?

I'm not really sure...

Conceivably then, a typical e-commerce site could have its product catalog browsing phase built with Model 1 JSP and a seamless transition to JSF for the more intricate UI interactions of the account-creation/check-out phase. Does this sound like a good approach?

Yes. You can do a series of light weight pages that are supported by page beans-- so it's still a good idea to put your logic elsewhere. But when you need more complex interactions... such as viewing a cart w/ quick item entry, validation, multiple updates, sorting, paging, transactions, ajax, etc-- then have you instead link to 'cart.jsf'.

Great, thanks Jacob. I think I'm on the right track now and know what I need to learn more about.

I've been hesitant to jump over to JSF because I didn't want to fall into the trap of over using it -- applying it to situations that it really wasn't designed for and suffering unwarranted development overhead -- like how EJBs were often applied innappropriately.

But I'm starting to see that, as JSF 1.2 plays nicely with other parts of the Java EE web-tier stack, I can take a pragmatic approach of using Struts, or even Model 1 JSP where it suffices, and introduce JSF components where it makes the most sense. Instead of searching for a framework that spans the full-spectrum of UI requirements, I will employ set a set of strategies for how to best leverage the Java EE platform. If done right, my team can employ the simplest approach that meets a project's initial requirements and then, as the project's requirements inevitably scale up, have a smooth transition to more sophisticated approaches.

It would be instructive to have a case study that follows the evolution of a simple Model 1 JSP-based application to a mix of JSP and JSF as UI requirements become more intricate.

Instead of searching for a framework that spans the full-spectrum of UI requirements, I will employ set a set of strategies for how to best leverage the Java EE platform. If done right, my team can employ the simplest approach that meets a project's initial requirements and then, as the project's requirements inevitably scale up, have a smooth transition to more sophisticated approaches.

It would be instructive to have a case study that follows the evolution of a simple Model 1 JSP-based application to a mix of JSP and JSF as UI requirements become more intricate.

I've brought this up a couple times in various web framework talks that JSF, the beast, is customizable at different levels, allowing other frameworks to customize or extend the component or model aspects of JSF. I still think there's opportunity to bring a strong Java API, like Wicket, to JSF.

I'm still playing around with alternate ways of managing state with JSF-- even going stateless in some cases because of JSF's declarative nature (guarantee repeated behavior for every request). There's tons of possibilities to basically re-write parts of JSF you don't like-- for me it was JSP with Facelets, but I'm currently nose deep in Tomcat 6 and I've grown a strong appreciation for some of the new modifications to JSP.

If you wanted to use JSF without the stateful components, I could very much see a custom ActionListener that leverages the rest of the JSF stack while keeping the overhead/mechanics along the lines of Struts or WebWork with multiple IoC backings via the new EL.

I try to keep a consistent pragmantic approach to my involvement with JSF-- while there's really sweet stuff offered in these other frameworks and fresh ideas (such as Wicket), I feel vesting time into enhancing a standard spec will help the Java platform. Again, anything you don't like about JSF, re-write and plug-in :-) Maybe this my cry to get frameworks aligned to JSF instead of the Servlet spec-- maybe that's my next blog over at Java.net ;-)

So your 1st choice would be to use Wicket, a component-based framework, to build a database publishing site like http://imdb.com?

Oooow, I see lot's and lot's of components! I see nested tabs, panels, lists (with panels) and more. When I look at that page, my natural reacion is to draw imaginary boxes around all that blocks and I see self contained components everywhere. Things like the blocks on the front page 'born today', 'upcomming this week', the search forms, 'quote of the day', the poll question, etc, etc. All neat little things that can be (and should be) developed completely independent of the rest of the page so that they can be put in any page you like afterwards, with or without ajax without a consequence.As these pages are largely read-only, it wouldn't be too difficult with other frameworks either. In fact, using model 1 would be easy, and using a model 2 framework wouldn't have any advantages for this site imo.But using Wicket for this site wouldn't slow me down at all now that I 'unlearned' (HLS tm) scripting and model 2, and in general I enjoy working with Java directly much more than I do working with JSPs etc.

For the most part I agree with what Eelco is saying on this one. _But_ I also don't really think "component" when I see imdb.com. Meaning although there are lots of little boxes and separate logical chunks to the UI they could all be handled by including "component" JSPs or by componentization as described by Jason in regard to WebWork - and that description usually gets him in trouble with componenent-framework fans.

Where I imagine that Wicket, JSF et al really come into their own is in stateful-component UIs. Imagine a version of IMDB where all of those widgets didn't bring up a new page, but brought back the same page with exactly the same data everywhere else, and updated information in that widget. That's hard to do, and a real strength of component frameworks.

My personal opinion is that a really well built action-oriented framework (or whatever you'd like to call non-stateful component frameworks) is easier to deal with in all other situations, even accepting and parsing complex input. But that's just my 2c.

-Tim Fennell
Stripes: Because web development should just be easier

My personal opinion is that a really well built action-oriented framework (or whatever you'd like to call non-stateful component frameworks) is easier to deal with in all other situations, even accepting and parsing complex input. But that's just my 2c.

I believe that it would be wrong to put an equality sign between an action-oriented framework and a non-stateful framework. Action-oriented framework can be stateful, and statefulness can simplify development significantly.

Also, despite one's opinion on whether non-stateful frameworks exist or not, iteractive applications themselves are usually stateful. Websites like IMDB are not truly interactive applications, they are just a Façade for an OLAP system. Stateless programming and stateless frameworks works well for OLAP systems, but OLTP application requires more state to save at the same time ensuring the freedom of navigation for better user experience.

Thus, there is always a necessity to store application state in an interactive application. Since traditional webapps are built on a series of HTTP requests, the state must be saved between requests. If a framework itself does not provide state-management services, an application developer would have to manage state manually, either in database, or in a disk file, or in a custom memory object, or passing it between browser and server as hidden field, or on client side using Javascript... Whatever the solution, the state must be managed somehow.

Therefore, it seems logical to use a stateful framework to build a stateful web application instead of using a stateless framework for this matter and to manage state manually.

On the other hand, passing state in form of URL parameters and hidden fields between browser and server does not count as stateless. This approach is not only stateful, but it ties pages/locations into an inflexible chain of requests/responses that cannot be broken. Step away from this chain and you lose the state. Page flow engines try to remedy the issue by ensuring strict page flow, but they cure the result, not the cause.

choose two frameworks (whichever), throw the others, and forget the past.

Which ones? ;-)

I prefer Mentawai (www.mentaframework.org) because:

1 - It has a extreme powerfull controller
2 - It is really very, very simple
3 - It is easy to learn, even if my team has not much experience
4 - It has others features that really help me at my dayly software development (like Hibernate transction management, sending mail, data lists, IoC & DI)
and more...

Seems to me that all of these frameworks including Wicket are "page" based frameworks in that you must have either an .html or .jsp file or some other file in order for it to work. Also, you have to deal with the html or javascript or jsp tags. I prefer frameworks that allow me to not even think about javascript, html and jsp like Echo or WingS. All you use to develop in these frameworks is Java.

Seems to me that all of these frameworks including Wicket are "page" based frameworks in that you must have either an .html or .jsp file or some other file in order for it to work. Also, you have to deal with the html or javascript or jsp tags. I prefer frameworks that allow me to not even think about javascript, html and jsp like Echo or WingS. All you use to develop in these frameworks is Java.

Those frameworks are very tight for certain types of applications, but the main problem is once you hit a complex layout or have to do many readjustments to the ui, you run into the same issues swing has.
Well not as bad as Swing thanks to CSS but still.

I have written applications with Echo that have had pretty complex layouts and it seems to me easier than the page based approach. If you use the CSS functionality within echo changes to the ui should be easy.

I have written applications with Echo that have had pretty complex layouts and it seems to me easier than the page based approach. If you use the CSS functionality within echo changes to the ui should be easy.

Yes complex layouts are possible with a pure java approach, so is Swing, but face it once you hit the situation of having webdesigners doing the page for you you end up in a huge mess of having to transform the markups into classes. Then you run into the situation of getting in constant layout changes, having a bunch of web designers not doing css properly etc.
What we have here with such frameworks basically is the problem of trying to transform something way out of html to html on the fly instead of going for an mvc model with a htmlish ui layer and only having to concentrate on the controller and model side of things while webdesigners can hack away their layouts.
Tell me one person being satisified with swings approach of coding everything in java and I can show you about 10 persons screaming for an abstracted ui definition language so that they finally can get rid of all the glue code messing up their entire project.

Seems to me that all of these frameworks including Wicket are "page" based frameworks in that you must have either an .html or .jsp file or some other file in order for it to work. Also, you have to deal with the html or javascript or jsp tags. I prefer frameworks that allow me to not even think about javascript, html and jsp like Echo or WingS. All you use to develop in these frameworks is Java.

I would say that Wicket is markup based, but I guess everyone gets the idea.

This is an example where it is good to have actual choice. Echo is one of my favorite frameworks for how the code (of the framework) looks. But personally I wouldn't like to develop with it because it imposes too many restrictions (no back button support and bookmarkable urls for instance) and it abstracted the layout while I think HTML and friends are excellent at that. But in some cases I can see advantages too in these limitations and programming model. So to conclude I think Echo is a perfect example of a high quality framework that fills in a gap other frameworks don't. I'm glad there is Wicket AND Echo AND WebWork AND Rife AND JSF to choose from.

Jsp , custom tags and controllers are the root of all misery. That combined technology is so crappy that I can hardly find words to describe it. The wicket, tapestry and rife way is already a lot better but still template based. Echo STYLE is the way to go, no templates there to screw everything up. Am I the only one that sees the danger of templates. Have a few persons in your team that dont get it and your project goes down the drain real fast. With templating everything becomes a trick, forget OO also with templates. Templates break everything that is good in programming. Stop the brainwash. Stop it!

Wicket is NOT a template framework. Wicket is OO manipulation of markup. There is a big difference between these two things.

Gentlepeople,

The main intent of my article was to introduce Wicket, and to do that I used the 'comparing web frameworks' series from Simon. The article actually doesn't compares anything to other frameworks but serves as a reference of how things are done in Wicket. I could have chosen any framework, by the way, but I liked the concepts presented in Wicket.

My intention was never to create a flame war. I'm sure there are many other frameworks out there that are as easy to work on as Wicket. The fact that they do things different is really irrelevant, except that people will always choose whatever they think it's right for them.

From my experience, what many frameworks really need is good documentation, that can be understood by beginners and experts alike. My only hope for what I wrote was to provide an easy to understand information on Wicket. You're more than welcome to do the same for the other frameworks out there.

Programming should be all about having fun...

Gentlepeople,The main intent of my article was to introduce Wicket, and to do that I used the 'comparing web frameworks' series from Simon. The article actually doesn't compares anything to other frameworks but serves as a reference of how things are done in Wicket. I could have chosen any framework, by the way, but I liked the concepts presented in Wicket.My intention was never to create a flame war. I'm sure there are many other frameworks out there that are as easy to work on as Wicket. The fact that they do things different is really irrelevant, except that people will always choose whatever they think it's right for them.From my experience, what many frameworks really need is good documentation, that can be understood by beginners and experts alike. My only hope for what I wrote was to provide an easy to understand information on Wicket. You're more than welcome to do the same for the other frameworks out there.Programming should be all about having fun...

And thanks a lot for writing that article Guillermo! I think this thread is relatively nice so far. There is nothing wrong with people questioning choices we made. We're happy to explain them, and it's fine to disagree with each other sometimes. And some public discussion like this hopefully enables people to choose better.

Gentlepeople,The main intent of my article was to introduce Wicket, and to do that I used the 'comparing web frameworks' series from Simon. The article actually doesn't compares anything to other frameworks but serves as a reference of how things are done in Wicket. I could have chosen any framework, by the way, but I liked the concepts presented in Wicket.My intention was never to create a flame war. I'm sure there are many other frameworks out there that are as easy to work on as Wicket. The fact that they do things different is really irrelevant, except that people will always choose whatever they think it's right for them.From my experience, what many frameworks really need is good documentation, that can be understood by beginners and experts alike. My only hope for what I wrote was to provide an easy to understand information on Wicket. You're more than welcome to do the same for the other frameworks out there.Programming should be all about having fun...

And thanks a lot for writing that article Guillermo! I think this thread is relatively nice so far. There is nothing wrong with people questioning choices we made. We're happy to explain them, and it's fine to disagree with each other sometimes. And some public discussion like this hopefully enables people to choose better.

I agree with Eelco. I don't think this has turned into a flame war at all. In fact I think it's admirable to have a civilized, respectful, open-minded discussion of technical issues, and it makes for an interesting, informative read.

I don't think anyone could accuse you of posting flame bait, Guillermo :-)

JustMy2c
Frederic

While we are talking others are working :) Simon rolled out another version of his test app, now using Stripes. Stripes seems to be the cleanest approach to an action framework that I've seen.

For those that are interested, I wrote a similar article about the RIFE framework:
http://rifers.org/blogs/gbevin/2006/3/16/comparing_web_frameworks_rife

Best regards,

Geert