A Wicket Diary

The vote is running, and things are looking bleak for the wicked Wicket 2.0 constructor change.

What is that constructor change you might ask? Well, currently you construct your component hierarchy using an add method as can be seen in the next example:

public class MyPage extends Page {
    public MyPage() {
        add(new Label("label", "Hello, World!"));
        Form form = new Form("form", ...);
        form.add(new TextField("field", ...));
        add(form);
    }
}

As you can see, you can construct components and add them to the component hierarchy at will. This has advantages and disadvantages. One disadvantage is that you don’t know the component hierarchy until render time. This puts extra burden on building Ajax components that require to know the markup id to do some JavaScript magic.

You can’t use some functions in your component constructors, such as getPage (the component isn’t added to the page yet), getMarkupAttributes (you don’t know where to look for the tag of the component, it is not added to the page).

There are more motivations to embark on the quest for the Holy Grail, and we went for it. The previous example looks like the following in the post constructor change (SWT style component wiring)

public class MyPage extends Page {
    public MyPage() {
        new Label(this, "label", "Hello, World!"));
        Form form = new Form(this, "form", ...);
        new TextField(this, "field", ...));
    }
}

As you can see, we now provide the component constructor with the parent, solving the previous gripes. After working about a year on it and with it, we found that the grass actually isn’t greener on the other side. Going back and forth, we now have a vote on the future of the constructor change:

When	What
Now	Backport the Model refactor and other remaining non-JDK-5 features from 2.0 to the 1.3.x branch.
Soon	Release a 1.3.0-beta to the community.
Soon	Release a 1.3.0-rc1. [2, 3, etc. if required]
A bit later	Release a 1.3.0 final. Fork a 1.4.x branch from the 1.3.0 release. Apply generics and other JDK-5 features to 1.4.x branch. This will make 1.4.x look just like 2.0, but with the same constructor/add logic as 1.2.x/1.3.x currently have.

• “now” ~= right now.
• “soon” ~= within a couple of weeks.
• “A bit later” ~= within a month or so.

We will discontinue support for 2.0 once we have branched 1.4.x and
added generics support into it, at which point the 2.0 branch will be
renamed in subversion and left to stagnate.

As already thrashed out in various discussions, this will achieve the
following:

• Provide a migration path for 2.0 users within a month or so, so they
  are not left high and dry. 1.4.x will be basically the same as 2.0
  currently is, only with the constructor change backed out.
• Give us two branches that will be very similar apart from JDK 5
  features, and thus make it easy to back-port fixes/features from
  the 1.4 branch to the 1.3 branch.
• Give us a 1.3.0 beta that is feature-complete, and thus make
  upgrading from beta >> RC >>final releases trivial.

I voted +1 for this, because I think the API break creates a too big chasm in our community, which would force us to fork our effort or to abandon (the larger) part of our community. Both are things I don’t like. The upgrade path seems reasonable and will not let our early adaptors out to dry. Yes you have to do some effort to revert the constructor change, but we will do our best to get the other features as quickly available in the current and next Wicket version as possible.

This entry was posted on Thursday, March 15th, 2007 at 11:00 am and is filed under wicket. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.