Apache Wicket

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.

Howdy!

Posted in apache, jsf, jsp, myfaces
29 comments on “Apache Wicket
  1. 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.

  2. 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.

  3. Eelco Hillenius says:

    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!🙂

  4. matthiaswessendorf says:

    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 ?

  5. Eelco Hillenius says:

    > 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.

  6. Niall says:

    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

  7. Martin Marinschek says:

    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

  8. Al Maw says:

    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.

  9. matthiaswessendorf says:

    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).

    • wicketDOESsuck says:

      It is too bad that you backed down, because Wicket really DOES suck. Its very underlying purpose is itself a fallacy. Let’s paraphrase what the basic idea is. Hmm, Java programmers are too stupid to understand client-side web development…so let’s make a framework that allows them to generate a client-side full of hooks to server-side code! This way, they can do cool client-side stuff while being totally isolated from it!

      Brilliant idea! So now instead of spending time learning about client-side web apps we’re going to spend time learning about Wicket. After all that, operations that require no server-side interaction will generally make a round-trip to the server. This makes for happy (lazy) programmers, user experience be damned! And hey, don’t worry about dumping the client-side state on the server…because memory is cheap!

      I know what you’re thinking (well, if you don’t agree with me that is). “But you can call js from Wicket, so your complaint is moot!” …or how about, “But you there are plenty of cool plugins around” That’s great! So we’ve added a bad layer of abstraction to our development process and then, upon realizing its limitations, piled some hacks on top of it. Oh…that’s rich.

      As a professional Java developer I see far too many older guys with this fantasy that experienced developers belong on the server-side. As more power transitions to the client-side, these fools continue plodding on with this delusion. They use frameworks like JSF and Wicket, and their UI DOMs go 100+ levels deep, most of those levels table, tr, and td. Such ugly garbage piled on top of more garbage.

      Learn CSS, then learn either JS or use GWT. Or, make yourself feel better while those who don’t resist the future end up outperforming you.

      • CouldntAgreeMore says:

        Greatest.
        Comment.
        Ever.

        Too many times do I see articles/reviews that start off evaluating an architecture and giving great points until *WHAM* “I hate Javascript” or “I don’t want to mess with Javascript/CSS” comes up. As a developer who does both, I find that if you use the right tool for the job, your life is much better and your project more maintainable. People who do client side development from the back end only know how to use a hammer and think everything is a nail. I feel sorry for these poor pathetic souls.

  10. cagataycivici says:

    Here’s what I think: Nodobody cares about wicket and JSF rocks.

  11. karthik says:

    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.

  12. Gopal says:

    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?

  13. Peter Thomas says:

    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/

  14. Selva says:

    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).

  15. UI-centric says:

    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.

  16. A passer by says:

    @UI-centric
    I’m afraid you don’t seem to get it. A little analogy is worth a thousand words :
    Think of Adobe Flex, which is abviously UI Centric : XML Markup to descibe your UI, actionscript classes describe its behaviour.
    Now think of Wicket and its approach : (X)HTML to describe your UI, Java to describe behaviour.
    So saying Wiket is not UI centric is a bit like you still don’t picture it

    • DoesntDrinkJavaKoolaid says:

      As a another fellow passer by, I think your missing the point. While Wicket proudly pounds it’s chest that it has separation between Church and State (HTML and Java) and the UI developer has his/her own world, it is hiding the fact that Wicket is injecting crap javascript left and right. A UI is more than HTML markup. UI includes front-end scripting langauges. I’m willing to bet you hate Javascript and CSS, mainly because you haven’t learned them.

  17. kevin says:

    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.

  18. Nendina says:

    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,,

  19. Rick O'Shay says:

    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.

  20. ninomartinez says:

    Rick, wicket has never claimed to be more than a web renderer. While seam is a full stack framework. If you want you can stack wicket with seam, or do something yourself like guice+jpa provider & wicket.. So yes wicket is not a database framework or injection framework. And I think that most would hate to see it go down that road. With wicket youre free to chose what ever you want of stack, it’s just java🙂

    As a side note, wicket emerged at the same time as Rails, and I think actually a bit before.

  21. Ed Burns says:

    I’d love to see a wicket lover reevaluate JSF in light of JSF 2.

    • Disappointed in JSF says:

      JSF 2 is still the same disabled framework as JSF 1.2, difference is wheelchair.

      It was burn to be slow. Backbuttoning? Forget. I get lost in the mess of tags. I get lost in the mess of beans and scope.

      Components? Ajax? Yeeeess. Yet another spike-nail. Hello plenty of libraries still badly working with each other.

      Java specs are violated. Least surprise rule are violated. Leaking abstractions everywhere.

      I can’t decide what is more evil – JSF or IE6.

      In two words – must die.

    • Disappointed in JSF says:

      Wicket is weak in providing the base for commercial libraries. It is pretty capable but does not advertise it well.
      I hope Wicket guys will eventually find someone who present them some money for advertisement.

  22. serverCentricLol says:

    Wicket is awful. The very philosophy it is based on is terrible.

    Suppose you want to create a rich web client. Instead of actually putting some behavior on the client Wicket instead puts a bunch of hooks to server-side code. Right off the bat we’ve sacrificed performance for *supposedly* simplicity and maintainability. But exactly how is this new layer of abstraction more simple or maintainable? We’ve just traded one complexity for another, and I think a very good case could be made that Wicket is no less complex than any of a variety of other solutions. So for a rich web app, we sacrifice a true client/server system for some silly client-full-of-hooks server-centric workaround. All because so-called developers want to insulate themselves from doing things THE RIGHT WAY.

    You might then say, well ok but for apps with relatively simple clients Wicket is great! To which one could easily counter, why the HELL use a bizarre layer of abstraction like Wicket if the client is simple!

    If you’re too scared to write JS, then use GWT. If you don’t want a rich client, then simple HTML will suffice and there’s no need for another layer of abstraction. Wicket is a hack based on a bankrupt philosophy.

    Server-centric frameworks like JSF and Wicket were created by the outdated fools who think client-side development is some lowly task unfit for an experienced server-side developer. Guess what? These days a good developer does BOTH. And no user is EVER impressed by a good server-side. They might complain about a bad one, but no server-side implementation will EVER score points with users. Those points can only be scored by the client-side, and those who try to isolate themselves from it will be washed away by the tides of change!

  23. Bruno Borges says:

    I think we all should stop blogging about “first impressions”.

    They are always flawed.

    I’ve worked with JSF before, for serious projects, and with Wicket as well.

    My “serious impressions” are not on the field of technical comparison, but rather in a programmer experience during the development process. And also in the field of a political comparison. For this last one, I’ve given a presentation months ago, and you can find the slides in here:

    http://www.slideshare.net/brunoborges/apache-wicket-derruba-o-padro-jsf

    The slides are in pt_BR, but if you go to slide 20 (after having the first 2-3 slides), you may understand what I’m talking about political comparison.

    Here, I put my ideas on those slides translated to English:

    – JSF is not a final product and so, does not really define a standard. Just a lifecycle and some basic components.
    – Because of that, projects must choose an implementation. Problem is: there are lots of implementations. You will have to choose only one.
    – Because of component incompatibility, it is hard to use more than one. Some components are independent, like a4j, Seam components and others.
    – Interesting components never end up into the specification. Takes too many years for that to happen (blame JCP)
    – Decentralised documentation. Because of different vendors and community components, you have to have a huge bookmark folder to look for when some issue comes up. Examples: mixing components.
    – Decentralised community. Don’t need to say anything about it…

    The advantages of JSF happen to be the same as for Wicket, Tapestry, SpringMVC or any other framework out there:
    – Common knowledge. If a programmer states he knows JSF, he’s able** (not proficient) to work with RichFaces, Mojarra, OpenFaces, ICEFaces, MyFaces, WhateverFaces. If a programmer states he knows Wicket, SpringMVC, Struts2, Whatever, he will probably be PROFICIENT to work with that.
    – Continuation. If people are using, probability of continuation is high. I mean, Struts2 and SpringMVC are alive.
    – Vendors and support. With JSF, you have different vendors, and so, a strong market pushing its use in the pursuit of profit. With Wicket, Struts2, Tapestry, RoR, that happens too, but it isn’t something so exposed.

    A fight between JSF and other frameworks should not be technical. We should stop doing that, because if you take two great programmers of each framework, giving them a use case to implement, they will all deliver in the same time.

    We should stop doing that. Let’s take this discussing to another level: learning curve, business strategy, documentation, development process and programmer experience day-by-day.

    Truth is, there’s no perfect web framework, but surely there’s a perfect web framework for each case.

  24. davut says:

    I am sorry but JSF is dead. It has no more chance to hide behind Java Standard stuff wordings. Wicket rocks! And the only alternative to Wicket is Play! Framework, not JSF..

    There is one big advantage of Wicket. It clearly separates HTML and Java layers. And the HTML layer is pure HTML, so you can give it to any Web Designer and then he can simply open this HTML in any Designer tool. This is very important thing because it allows simple communication between Web Designers and Java Developers. Designer designs the HTML, and the Developer directly uses it without refactoring! This is Agile Development. And it is very important, beneficial development strategy today.

    No other framework supports Agile Development because other frameworks don’t use Pure HTML, they depend on framework specific tags too much.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: