Apache wicket: First experiences
We've recently started using Apache Wicket here in Workday. I have quite a bit of experience with front-end presentations systems in Java, starting with jhtml/ATG dynamo (ancient history pre-cursor to JSP's), XSLT/XML/HTML content rendering, cocoon, velocity, JSP's, page-flow, taglets, struts, JSF, spring MVC - luckily not all for Cape Clear / Workday (that would be crazy). Most had some useful bits, but serious drawbacks. For example, about the best thing I could say about struts is that it is "better than having nothing at all", it's main problem is that developers always had to think simultaneously in terms of pages/JSP code, actions, javascript (since there was always javascript involved). It really didn't simplify anything.
The continuations-style, where you code in terms of putting components on the page and then configuring event-handlers is a very powerful concept. It attempts to apply the sucessful graphical-component programming models of Swing/AWT to web-pages. In this model, the front-end framework manages the heavy-lifting of associating web-requests with pages, instances and event-handlers. Obviously this state-management costs (in terms of sessions), so YMMV in terms of framework you choose, how you use it and your expected load. On the standards front there is JSF which is popular. However, for me it is overly complicated and heavy (in terms of it's construction - but I hear they are working to reduce that). Also, you still inevitably end-up with quite messy JSP's (not scriptlet ugly, but still - not nice and more trouble to maintain than it is worth).
This is why wicket is so appealling. It is another continuation-style / page-component model - but it's philosophy is to leave the web page uncluttered and thus easy to maintain and share with web-designers. The central idea behind wicket is to have two parallel models. Firstly you have the web-page component model. This is very familiar to anyone who has ever programmed Swing/Swt. Even the naming of the components are deliberately similar. Here's an example hierarchy for a simple form.
The corresponding web-page is shown below. Note how clean it is. Only the wicket:id's are used to identify which bit relates to which bits in the corresponding java component model.
Wicket's strong-point is it's "do-it-all-in Java" approach and leave the HTML for just being the view (of the MVC). This is in start contrast to JSP which mixes logic directly into the HTML. The comes a point when working with it, where you stop thinking in terms of web-pages or the wicket framework and just laspe back into thinking in terms of java object models (which is really where you should have been thinking all the time). Wicket just helps you associate this java object/instance hierarchy with web-requests, basically it is really good at getting out of the way of you getting the job done.
Other nice things are:
So far we have developed three sets of new functionality. Each one involves searching for data, presenting it in paged tables and allowing editing with valdiation. The first one took us a couple of days (due to the documentation and lack of experience). The last two have really just been stamped out incredibly fast, now that we are a little further along the learning curve. I am astonished at how productive you can be.
The continuations-style, where you code in terms of putting components on the page and then configuring event-handlers is a very powerful concept. It attempts to apply the sucessful graphical-component programming models of Swing/AWT to web-pages. In this model, the front-end framework manages the heavy-lifting of associating web-requests with pages, instances and event-handlers. Obviously this state-management costs (in terms of sessions), so YMMV in terms of framework you choose, how you use it and your expected load. On the standards front there is JSF which is popular. However, for me it is overly complicated and heavy (in terms of it's construction - but I hear they are working to reduce that). Also, you still inevitably end-up with quite messy JSP's (not scriptlet ugly, but still - not nice and more trouble to maintain than it is worth).
This is why wicket is so appealling. It is another continuation-style / page-component model - but it's philosophy is to leave the web page uncluttered and thus easy to maintain and share with web-designers. The central idea behind wicket is to have two parallel models. Firstly you have the web-page component model. This is very familiar to anyone who has ever programmed Swing/Swt. Even the naming of the components are deliberately similar. Here's an example hierarchy for a simple form.
public class MyWebPage extends WebPage {
private String name;
public class MyWebPage {
add(new Label("title"));
Form form = new Form("myform");
form.add(new TextField("name", new PropertyModel(this, "name")));
form.add(new Button("hit") {
public void onSubmit() {
// do something - this is the event-handler
}
});
add(form);
}
}
The corresponding web-page is shown below. Note how clean it is. Only the wicket:id's are used to identify which bit relates to which bits in the corresponding java component model.
<html wicket="http://wicket.apache.org/">
<head>
<title wicket:id="title"></title>
</head>
<body>
<form wicket:id="myform">
<input wicket:id="name"/>
<input type="submit" wicket:id="hit" name="Push Me"/>
</form>
</body>
</html>
Wicket's strong-point is it's "do-it-all-in Java" approach and leave the HTML for just being the view (of the MVC). This is in start contrast to JSP which mixes logic directly into the HTML. The comes a point when working with it, where you stop thinking in terms of web-pages or the wicket framework and just laspe back into thinking in terms of java object models (which is really where you should have been thinking all the time). Wicket just helps you associate this java object/instance hierarchy with web-requests, basically it is really good at getting out of the way of you getting the job done.
Other nice things are:
- back-button support (which is a failing of a lot of continuation-style frameworks and flex-style plugins).
- data-table/binding support.
- stateless pages (if you want your pages to be stateless you can do it).
- bookmarkable pages
- integration with acegi security.
- unit-testing support.
- ajax support (including contributions for scriptaculous and prototype).
- it make sense - I try out undocumented stuff on the basis that it "should do X" and generally it does.
- access to the source (invaluable).
So far we have developed three sets of new functionality. Each one involves searching for data, presenting it in paged tables and allowing editing with valdiation. The first one took us a couple of days (due to the documentation and lack of experience). The last two have really just been stamped out incredibly fast, now that we are a little further along the learning curve. I am astonished at how productive you can be.
posted by Fergal @ 10:52 AM
2 comments
2 Comments:
Hi. Good to read Wicket works well for you and your team!
I endorse everything said, it has been my exact same experience. I too have used jsf, spring mvc, but never enjoyed using them - always had the feeling "there should be a btter way than this", and it turned out there was - Wicket !
Post a Comment
<< Home