Wicket is a Java Web Framework that uses POJOs and HTML to create applications. I read a lot’s of blogs that Wicket is so great, but never really bothered with taking it serious. When flying back from ApacheCon US, I read an article about Apache Wicket and I have to say, that I don’t buy the Wicket story, yet.
The key features of Wicket, as far as I got it, are:
- POJOs
- HTML pages
- no XML
A typical Wicket-HTML file looks like
<html> ... <span wicket:id="value">Some value</span> <a href="" wicket:id="link">Go there</a> ... </html>
The Java file behind the page looks like this:
public class MyPage extends WebPage {
public MyPage() {
Label valueLabel=new Label("value" ...);
add(valueLabel);
Link link=new Link("link") {
@Override
public void onClick() {
setResponsePage(hardCodedLinkToAnotherPage);
}
};
add(link);
}
}
Noticed it ? Yes, it uses Java…., but that wasn’t the point. The structure of the HTML and the Java is same. You kind of rebuild the thing in Java, what your designer did before. Also the navigation is hardcoded 
I am not sure if this all is really sufficient, when creating large applications, because it looks to me, that you are coding redundantly (HTML and Java).
In JSF you describe your view in a view-technology (Facelets, JSP, Clay,…) and behind you have a POJO object (managed bean) as well. It only captures the actual values. Sure you can code against the JSF-API, by using bindings. That allows you the creation of dynamic formulars, for instance.
What happens to Wicket, when I want to replace the Link class by an extension (FancyAjaxSomewhatLink for instance) ? Do I have to change all my classes ? In JSF the managed bean behind the page is somewhat independent from the “view-technology” as HTML, AJAX or even XUL, since it usually just captures the values. If you want to replace the default commandLink from the JSF standard API, by an extension, just change the declarative view, but you don’t have to touch the Java-code behind that page, like:
...
<ajax:myCoolCommandLink action="#{bean.theRegularActionMethod}" />
...
I like the fact, that there are different frameworks out there, but I belive in JavaServer Faces.
Perhaps it is worth to take a deeper look at Wicket, not sure on that, to be honest.
18 responses so far ↓
Jess Sightler // November 20, 2007 at 3:48 pm |
Wicket is clean and easy to work with, but I tend to agree with you about data binding.
JSF has the presentation layer contain databinding information.
Wicket has the data layer bind presentation information.
Neither approach is completely superior to the other, but I tend to favor the JSF approach for most environments.
Jonathan Locke // November 20, 2007 at 4:55 pm |
I believe you are missing the forest for the trees. There is an awful lot beyond those three bullets. It may take the effort of writing a full application (even a small one) to really wrap your head around Wicket. For example, the downsides you mention above are true from one perspective, but they actually have very significant upsides as well — upsides which are difficult to see if the whole world must-be-managed-because-that’s-how-we-do-things-nowadays. One really major upside of the above is that Wicket cleanly separates markup from behavior, and since ALL your behavior is in Java your refactoring tools will do such things like Link->FancyAjaxSomewhatLink. And of course, all other such Java magic applies to Wicket as well: your code is type-safe and secure, your state is managed transparently, you can create components with the extends keyword, your application can be debugged like any normal Java application, and what’s more you /could/ quite easily build a mapping layer for links if you wanted to (although nobody who uses Wicket actually seems to care about this)… and so on… the fact that wicket uses that id to keep code separate from markup is actually a huge advantage. I have worked on large-scale projects in Wicket and this does not repeat work the designer did, it actually (mostly) decouples what the designer does from what the coder does. I have been able to work for days or even weeks at a time without needing to work closely with our designer. Our designer is in heaven when it comes to Wicket. There’s very little she can do to break anything. She’s doing what she does best: design. And I’m doing what I do best: code. And never the two shall meet. This is actually really, really good.
I think what’s happened above is that you’re looking at Wicket as an apple and in that light it looks like a fairly crummy apple. But in fact, what you’re looking at is not an apple at all. It’s an orange.
Eelco Hillenius // November 20, 2007 at 5:05 pm |
Hi Matthias, a few comments…
What the key features of Wicket are depends of course on who you ask. When you say ‘POJOs’, I’d really like to say ‘POJO programming model’. Most if not all competing frameworks provide declarative programming models. Wicket provides a ‘plain Java’ model. To support straightforward OO programming, Wicket also makes a big deal out of managing state for you (remember objects are state + behavior).
As for the key benefits, my personal favorite is that Wicket scales really well for development and supports writing maintainable code. Also, Wicket is setup very layered, making it easy to tailor it for your needs (even up to writing your own tag handlers, which makes it even possible to bend Wicket into a JSF-like framework if you like).
> You kind of rebuild the thing in Java, what your designer did before.
You only match the structure for the tags that you make dynamic. The downside to this is obviously that it is more verbose and you have to keep things in sync, but the upside to this is that you have all your logic in Java and none in HTML (there are plenty of discussions out there that argue for this), and that you can very easily let components work in an hierarchy, which is particularly useful in complex pages/ components (think of data tables with filters etc).
> Also the navigation is hardcoded
Only as hardcoded as you want it. It is trivial to introduce an indirection for this. I think page flow is overrated, as I stated here: http://chillenious.wordpress.com/2006/07/16/on-page-navigation/. Furthermore, navigating to other pages like Wicket does, using page classes, also makes your application much easier to manage; just use your regular Java IDE to view where page X is referenced. Also, you can write pages like APIs, for instance, requiring them to be constructed with certain elements (a Person object/ model for instance).
> What happens to Wicket, when I want to replace the Link class by an extension (FancyAjaxSomewhatLink for instance) ? Do I have to change all my classes
Is that really a relevant case? Replace a form with a table maybe? I mean, replacing a regular link with an ajax link is not something you would do often without having to change anything else in the way your UI works (and if you want both, you can use Ajax fallback links), and examples beyond this are almost certain YAGNI.
And why is it better to change this in your markup, even though this is a behavioral change? With Wicket you wouldn’t have to touch the markup, and the fact that you’d have to change the Java part makes that you’ll have the compiler check that you meet the API requirements of the change.
*If* you would need such flexibility though, with Wicket you would use behaviors, which can even be plugged in as a cross cutting concern (e.g. with render listeners).
> but I belive in JavaServer Faces.
Wouldn’t be good for you nor your users if you didn’t!
matthiaswessendorf // November 20, 2007 at 5:44 pm |
Hi,
thanks for your comments.
My first impression on Wicket is that you “duplicate” things. I haven’t written an application with Wicket yet. Perhaps I should, to verify your comments
I like JSF (with Facelets) because:
-Designer-friendly as well (similar to your HTML pages)
-the backing bean are POJOs as the model behind my pages
(just to name two reasons)
In backing bean POJOs, I don’t need to create the JSF components, which I already declared in my Facelets view (like input jsfc=”h:inputText” value=”#{bean.myValue}”).
I write them (the backing beans) once. They call my (Spring)-Services for the communication w/ my business-layer. For tables, I can store my data in a java.util.List and via Expressions I wire my “table tag” and the “model” together.
Once I am done with my backing beans, I am done. I can replace the renderkit (like putting in Trinidad instead of standard JSF) and I simply can reuse those beans. I have to edit my “view template”, but not the java-code itself.
I personally think that both frameworks (Faces and Wicket) come from different sides. One comes from the left and one from the right (doesn’t mean correct
) to the center, which is the topic “Java Web Development”.
I really appreciate that there are several options out there and it’s always good to check other frameworks, so I did and blogged my personal opinions. Choice is good.
@Eelco: are you doing a Wicket training / session in Amsterdam, next ApacheCon ?
Eelco Hillenius // November 20, 2007 at 7:22 pm |
> I personally think that both frameworks (Faces and Wicket) come from different sides.
Exactly
> are you doing a Wicket training / session in Amsterdam, next ApacheCon ?
I submitted a proposal. Hope to get in this time. I hope to be at that ApacheCon, though as I have to come from Seattle, it depends on whether I get to speak or not.
Niall // November 20, 2007 at 8:38 pm |
I guess its too late, for ApacheCon EU ‘08 – but I would love to see a JSF vs Wicket HEAD-TO-HEAD presentation, done in a friendly way
Martin Marinschek // November 21, 2007 at 11:06 am |
For a while, my problem with Wicket was that it came late to the table – why reinvent the whole thing, if you could join efforts with one of the existing frameworks? Eelco has answered on this some time ago (he wanted page-definitions purely Java-based, this wasn’t available, the JSF community wasn’t interested, Tapestry wasn’t an option obviously), so I do understand why this happened…
In the end, I have always been of the opinion that Wicket was purely Java-based, and didn’t use HTML-templates at all. After some discussions at W-JAX, I do see the additional problem Matthias introduces here. Duplicating the structure introduces redundancy – is this really necessary? Aren’t we living in a world where we try to reduce redundancy? Why do we have the page-structure in HTML and repeat the same thing in Java? I still don’t understand how this helps the designer and the coder – or how you want to build more sophisticated components with this approach.
With the same argument we could strictly separate the representation of the domain in the database and in the code – however, in most applications I’ve seen, people try to see this as something similar and try not to repeat themselves when designing the domain model (Ruby on Rails, Hibernate Generation tools, etc.).
However, I understand the need for template-based components – that is very relevant. So if Wicket HTML-templates would define components only, and I could define my page fully in Java, I’d be happy. Is this an option in Wicket?
regards,
Martin
Al Maw // November 21, 2007 at 2:54 pm |
Hmmm. I’ve yet to find anyone who has done anything serious with both JSF and Wicket prefer JSF over Wicket. Quite the opposite in fact. IMO, it very much is the case that you haven’t done anything serious yet.
This blog entry is generally misleading and ill-informed – your statement that “links are hardcoded” is quite laughable. “hardcodedLinkToAnotherPage” in your example will actually be SomePage.class or new SomeOtherPage(withSomeParameters); Obviously that’s all just Java code – you can change it and add logic in the onClick() to do whatever you like. If you want a variable number of links at some location in your page, that is really easy to do with a RepeatingView component. You can’t just insert links at an arbitrary location in your page using only Java because, well, how would you define where to put them? By writing a bunch of code that manipulates a DOM tree or something? Ick.
Regarding your last comment, why do you want to define your page only in Java, with no mark-up? If you prefer JSF, then you’re doing the opposite – you’re pushing quite a lot of the logic into the mark-up, with lots of special JSP-alike tag soup. With Wicket the whole point is that the markup and logic are separated. OTOH, if you want your code to define your layout and not have to write any HTML at all, go and look into GWT.
matthiaswessendorf // November 21, 2007 at 3:26 pm |
I am not saying that Wicket sucks. I just made some comments on my first impression (as pointed out here). As far as I know it also doesn’t say, that it is the complete reference for a comparison
In JSF I like to have a declarative view. The bean behind the page is something, that I’d call “lightweight page-controller”, since it “works” with the data (for in/output) and *delegates* calls to a (spring managed) service.
So my controller is really a pojo and hasn’t to create “components” (I could do that with bindings as well).
By that I have two separate things:
-page declaration
-POJO page controllers (to name the managed beans that way)
Both are clearly separated and I can easily change the used RenderKit (meaning new components).
cagataycivici // November 24, 2007 at 2:41 pm |
Here’s what I think: Nodobody cares about wicket and JSF rocks.
karthik // April 8, 2008 at 5:04 pm |
One nice unique thing that I like about Wickets is that the HTML markup code is left undisturbed. At any time, my business manages multiple web projects (small & medium sized clients) and it used to be a pain when developers make UI changes or the UI designers messing up with JSP tags. We always outsource our web design (or buy templates from millions of sites over net, sometimes even quality tempaltes for free !!). This has lots of benefits
- very cost effective in getting and deploying HTML pages
- easy to out source the UI work (and as you know, a great GUI pulls in customers and that what makes the client to pay you $$).
I am not sure about other technical pros/cons, but Wicket gives us more profit margin for sure.. and easy to make quick changes too. We also use the OpenXava for manaing internal admin tasks, as it auto generates everything.. kool one. Combining stuff like these helps in fast development..
my 2 cents.
Gopal // April 18, 2008 at 5:45 am |
Isn’t it Barracuda framework was doing the same thing as wicket? I have used Barracuda 6/7 years back exactly for the same reason namely separation between markup and java. Why do we Java developers had to cross the same starting point again and again?
Peter Thomas // June 2, 2008 at 1:50 pm |
I have some presentation slides on the advantages with the Wicket ‘pure Java’ approach (includes a comparison with JSF) here:
http://ptrthomas.wordpress.com/2008/05/26/migrating-to-apache-wicket-presentation-slides/
Selva // August 9, 2008 at 9:26 am |
First of all i want to praise that this blog is so nice.how to add image in a wicket’s html file(java method to add an image).
UI-centric // September 11, 2008 at 11:23 pm |
I cannot wrap my head around Wicket either.
Wicket seems to be written by people who hate DHTML and DHTML designers. The evidence is in the New User Guide which states their major complaint against JSP, JSF, etc.: “But now our Java code is a second-class citizen, existing merely to provide the page with the information it needs while it renders itself.”
So the Wicket creators go out of their way to wrestle control back to the Java programmer. With Wicket, whatever DHTML carefully crafted by the designer is discarded and recoded in Java. And with a lot of Java. The Wicket framework itself has a quarter million lines of source code.
What troubles me the most is that Wicket is a giant step backward against UI-centric programming. Since web apps are user-centric, the development should be centered around the HTML Web page. The server is merely there to provide/save data to/from the page. Not the other way around. But since most server-side Java programmers hate UI (favorite dismissal: “Just GUI sugar.”), they love Wicket as a sweet revenge, hence the popularity.
kevin // December 9, 2008 at 7:29 pm |
One advantage Wicket has that I almost never hear people talking up, but can’t understand why, is testability.
Now, I’m pretty new to the industry but my impression is that compared to Java, Javascript is incredibly difficult to unit test and debug. Sure, there are good tools out there like Selenium and Watir, but JUnit is just too easy. And Wicket provides this “out-of-the-box”. Statically-typed, debuggable, familiar-to-the-industry, “testable sugar”.
Lack of testing is just fine if you’ve got a small project with 5 or so developers where everyone knows every line of code, but what about a banking application? Or an internal corporate web-tool? In these cases, form always follows function and there are great (and trusted) J2EE tools already available that Wicket can take advantage of. Nobody who’s worried about a bottom-line is going to sacrifice testability that already exists in order to give some fancy drop-downs to their accountants on the second floor.
That’s not to say you can’t get fancy with Wicket. In fact, I’d be willing to bet that future versions will provide more robust Ajax components, that, with a little CSS, will give most people everything they need. In fact, during the simple demos I’ve done for my co-workers people always ask if Wicket is an Ajax framework, when in fact I never include Ajax at all! That’s because the state-handling is done so well, it almost looks asynchronous. So, if I can give my users a flexible state-driven workflow AND maintain my test coverage, it’s a win-win.
And what’s wrong with not fully embracing brand new technologies? We haven’t even perfected the ones we’ve got. Don’t think of Wicket as trying to reinvent the wheel, they’re just making it a little rounder, that’s all.
Nendina // December 30, 2008 at 10:27 am |
I guess it is really hard to wrap your head around Wicket, where JSF provides the more traditional WebDeveloper approach by mixing up presentation+logic (think ASP, php, JSP, etc) and in that sense I understand the ‘critical’ comments about Wicket.
On the other hand, I can’t stop thinking ‘What are you guys talking about’?
For example:
> What troubles me the most is that Wicket is a giant step backward against UI-centric programming. Since web apps are user-centric, the development should be centered around the HTML Web pagNot the other way around. But since most server-side Java programmers hate UI (favorite dismissal: “Just GUI sugar.”), they love Wicket as a sweet revenge, hence the popularity.
That’s clearly rubbish, something invented in a mind, not in reality. I’ve been doing lot’s of Wicket+YUI coding for the last 8 months, and yes, it took some time to get used to, but I’m so happy that I’m not messing around in .html files anymore..
Anyway, I think most of the complaints I read about Wicket are based on dogmas and old believes, people not being able to look any further than what they know/understand. It’s what makes the world go round I guess,,
Rick O'Shay // March 17, 2009 at 5:18 pm |
Wicket is yet-another addition to the zoo of sweetspot frameworks. The same thing we see with Ruby on Rails and its antecedents.
Looks like nice clean separation of view and backing-beans but no substitute for Seam or the poor man’s Seam, Spring. I can see using Wicket as the view tech on Seam, seems like a nice combo.