The Apache Wicket team is proud to announce the immediate availability of the newest release of their component oriented open source Java web framework. Apache Wicket 1.5 has been in development for the last two years and brings many improvements over previous versions.

With this release the Wicket team has revised many of its internals. A short list:

• HTML5 components added: EmailTextField, NumberTextField, UrlTextField and RangeTextField
• New inter-component events (explained below)
• Minimum required servlet API is servlet-api 2.5
• All standard validators now extend Behavior to allow for client side validations
• IBehavior has been removed and AbstractBehavior has been deprecated, you should now extend Behaviorinstead
• Simplified the request cycle processing and made it more extensible
• URL handling is now in one place
• Wicket’s rendering code has been greatly simplified
• Improved browser caching support
• ClientSideImageMap replaces old ImageMap
• Better support for running behind proxies with x-forwarded-for header
• Request cycle listeners make it easier to integrate frameworks in your Wicket application
• Consistent naming: methods with Javascript in the name have been renamed to use proper capitalization:JavaScript
• Switching to HTTPS is as simple as configuring a new root mapper to make Wicket HTTPS aware and annotating a page with @RequireHttps

A longer list of changes and improvements can be found in the migration guide.

Read more here: http://wicket.apache.org/2011/09/07/wicket-1.5-released.html

Now, this is a framework which hasn't had much media coverage in 2 years. I thought it was dead, so recently we replaced our Struts 1.1 with GWT.

..still alive?

If I understand correctly, the recently launched new online banking site of the Postbank (a major retail bank in Germany) is implemented using wicket. So some big companies do not shy to invest in it.

I'm very excited to try out the new features.  Wicket is a great project.

Thanks to the wicket team for all the good work.

Can anyone report about their experience with Wicket in a typical enterprise environment - one, that would normally use JSF? Wicket looks promising and I'd recommend it if had more practical experience with it. Is the 'Wicket way' (just Java and Html) somehow limiting or not future proof? Are the Wickets components appropriate for ever changing customer demand? Is Ajax support good enough?

tl;dr is Wicket enterprise ready?

Is the 'Wicket way' (just Java and Html) somehow limiting or not future proof? Are the Wickets components appropriate for ever changing customer demand? Is Ajax support good enough?

We are using Wicket for some internal custom web applications.  So far the results have been pretty good.  I don't think that the Wicket model is limiting in any way.  In fact, one of the biggest strengths of Wicket is that it is very flexible if you have developers who are 'real' Java developers and not just framework jockeys.  In that way, there is a good bit of future proofing.

This isn't to say that Wicket doesn't provide a lot in itself.  All the security, session management, and clustering built into Wicket saves a lot of time and stress while allowing for extension.

The biggest challenge with Wicket is the limited documentation.  This is mostly a problem when you are just getting started as once you get a feel for the basic paradigm, it's consistently repeated and it tends to be self explanatory.  You might want to buy a book although I haven't bothered to do so myself.

Can anyone report about their experience with Wicket in a typical enterprise environment - one, that would normally use JSF?

Yes, we're using it for internal web-applications, it definitely beats JSF hands-down. We especially like its ability to fall back to plain old HTML forms if JavaScript is disabled or is not quite properly implemented (as it is on a lot of phones).

My biggest problem with Wicket is its verbosity. It takes a lot of lines of code to do simple things. On the other hand, it only takes a little more lines of code to do very complex things in Wicket.

Wicket looks promising and I'd recommend it if had more practical experience with it. Is the 'Wicket way' (just Java and Html) somehow limiting or not future proof?

'Wicket way' is fine once you get used to it.

Are the Wickets components appropriate for ever changing customer demand? Is Ajax support good enough?

Built-in Wicket components are pretty good and it's not hard to write your own components. Though DataTable component could use some improvements.

tl;dr is Wicket enterprise ready?

I would definitly say "Yes" in this respect. I have used Wicket in several customer projects now and I really love it. The development model - once you get it - is consistent and logical and I personally think that the Ajax support is superb. Also, it is quite easy to integrate it with jQuery, leading to a very powerful application framework.

I am currently developing a single page app where most of the page updates are done via Ajax and a lot of JavaScript stuff is going on and up to now, I have not had any significant problems.

The component choices my not be as good as for JSF, but I find the available components sufficient and, more importantly, easily extendable and customizable.

In summary, I would choose Wicket over any other web framework - including JSF - any day.

Cheers,

J.

Can anyone report about their experience with Wicket in a typical enterprise environment - one, that would normally use JSF?

We tried to start some new internal projects in Wicket some time back, but this wasn't a great success. The entire JSF ecosystem is just so much richer, and it's a lot easier to get into as well. At the end the Wicket experiment was abandoned and the stuff that was created in Wicket was re-created in Java (taking only a fraction of the time, although this isn't a totally honest comparison as the requirements etc were already worked out compared to the first development effort in Wicket).

These days, do make sure you're using at least JSF 2.0, so you can easily take advantage of things like the view scope, view parameters, and Facelets (including composite components) which are build in.

 

Wicket looks promising and I'd recommend it if had more practical experience with it. Is the 'Wicket way' (just Java and Html) somehow limiting or not future proof?

I personally prefer the main JSF way, where you have powerful templates with components. In JSF you can choose to put server side tags on your template, but you also use only plain HTML with a special extra ID to associate HTML tags with components (see http://en.wikipedia.org/wiki/Facelets).

Alternatively, you can write JSF pages using Java only without any templating or xml (see Auhoring JSF pages in pure Java) for a crude but working example.

(there is no -the- JSF way, as JSF is open to many different ways to compose a page, but Facelets with component tags seems to be most popular)

tl;dr is Wicket enterprise ready?

There have been some projects done in Wicket, but my guess is these were done in Wicket because programmers read some blog that shouted how great Wicket is and how bad JSF is (typically without providing real arguments). A major problem of Wicket is that it's just not that much used. This means it's harder to get answers (stackoverflow for instance is great for JSF questions, but not so great for wicket ones), and even harder to get people who already know Wicket.

The typical answer of Wicket fans is that Wicket is so simple it takes only an afternoon to learn, but this is nonsense. In that afternoon you know how to create a hello world application, which btw takes only 10 minutes in JSF (see Minimal 3-tier Java EE app, without any XML config).

After this afternoon (Wicket) or 10 minutes (JSF) you are of course not ready to do full fledged enterprise development. To learn the framework (any kind of framework) takes much longer, so if you can attract people who already know some technology it's simply an advantage.

There have been some projects done in Wicket, but my guess is these were done in Wicket because programmers read some blog that shouted how great Wicket is and how bad JSF is (typically without providing real arguments).

I don't want to get into the typical flame-war on  who's preferred framework is better than the others, I just would like to add the I have worked with both JSF and Wicket in customer projects and that Wicket way beat JSF before the 2.0 release as JSF was in many ways pretty much unuseable back then. With the 2.0 release some aspects have been rectified and JSF as the JEE standard now provides many of the features other frameworks have offered for years.

Still, JSF is the standard and as such considered by many people (interestingly enough sometimes not the architects/developers but the "decision makers") as the best way to do web applications. But as you have already pointed out, there is no single "JSF-way" and that leaves so much room for different solutions for the same problem that the "is the standard" point pretty much  diminishes.

Regards,

J.

One of the things about Wicket I like most is its ability to easily compose components.

Whenever I have to add a Date field, I don't write the whole new DateTextField thing adding a DatePicker to it. I already did my own Date component, based on the project's requirements such as formatting, ranges and so on. Things like form fields are always converted to reusable components whenever they are recognized as such.

I think that with Wicket, the amount of lines of code you have to write decreases during your project development. 

I did some projects with JSF, but writing my own components (or even worse: customizing existing ones) in JSF is a PITA. With WIcket is just a Java class, pretty much like Swing and if it has a custom HTML, it's just a file with the same name as the class.

If people want to build a project with Wicket, consider writing DSLs and improving custom components during the process. This is what makes Wicket projects so easy and productive.

One other thing I like the framework is the clean separation of HTML and Dynamic/Controlling logics. As architects we always want to separate layers, but when it comes to the View layer, we have so many sintaxes  (XML/HTML/Java/EL/OGNL/JavaScript/CSS) in one single file. This is a mess.

Whenever a customer comes to me to build a project, I first deliver to him a static but functional HTML prototype to get approval, then I reuse that as the Wicket base template. No conversions (from <form> to <s:form>) of HTML tags to Taglibs.

Which comes to one saying along Wicket developes I like to mention: "The best choice to code Pixel-Perfect web applications". (HTML/CSS layouts designed and coded by web designers)

I did some projects with JSF, but writing my own components (or even worse: customizing existing ones) in JSF is a PITA.

Ever looked at composite components in JSF? Writing them is extremely easy and customizing existing ones is easy too. It's just a file in a directory. You put html and binding in that file and it automatically becomes a component. No configuration or registration is needed (Convention over Configuration is an important theme in JSF).

With WIcket is just a Java class, pretty much like Swing and if it has a custom HTML, it's just a file with the same name as the class.

In JSF you can also create components solely in Java, see http://jdevelopment.nl/simple-java-based-jsf-custom-component/ , or you can have the same simple Java class and have the custom HTML in a separate file (which has the same straightforward layout as the composite component).

Whenever a customer comes to me to build a project, I first deliver to him a static but functional HTML prototype to get approval, then I reuse that as the Wicket base template. No conversions (from to ) of HTML tags to Taglibs.

This is also how JSF can work as shown by the following Facelet:

&lt;html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html">
    &lt;body>
        &lt;form jsfc="h:form">
            &lt;span jsfc="h:outputText" value="Welcome, #{loggedInUser.name}" disabled="#{empty loggedInUser}" />
            &lt;input type="text" jsfc="h:inputText" value="#{bean.property}" />
            &lt;input type="submit" jsfc="h:commandButton" value="OK" action="#{bean.doSomething}" />
        &lt;/form>
    &lt;/body>
&lt;/html>

As a matter of fact Wicket component model is too far from being perfect. The paradigm is that a component "With Wicket is just a Java class, pretty much like Swing" but that does not sit well with markup ideas. Where is the place of template here? - Apparently on a side-walk. Guys did not invent anything beyond following a paradigm from a different world ... and then they have nothing to tell besides that it was the best choice. All this results in a lot of duplication of information and in plainly unnecessary garbage - like treating each button on the page as a component or like having a loop in the presentation layer as a component too (all with separate instances on the server!).

Compare to HybridJava approach that instead of adding markup to VB ideology evolves the markup approach itself: http://www.hybridserverpages.com/

Also here is my (a bit obsolete) critique of Wicket in general: http://www.theserverside.com/news/thread.tss?thread_id=54866

The thing I love about using Wicket, is that I can have my web designer do his HTML and CSS magic and then I can take that same form as is, and simply add my wicket tags and that's it...I write my Java class and that's it.  Wicket Extensions has some nice AJAX components, out of the box,  but it's really easy to write your own custom AJAX objects.

My biggest problem with Wicket is its verbosity. It takes a lot of lines of code to do simple things. On the other hand, it only takes a little more lines of code to do very complex things in Wicket.