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.
We had a small discussion on how to make underwater photographs, and having minor experience myself with some equipment I told them that you need:
The digital camera is necessary to get instant feedback. You will be underwater for at most 30 minutes or so, and have at most 2-3 dives per day. When you use an analog camera, your learning curve will be severely low. Missing fishes, wrong light, half fishes, too far away fishes etc. All these things can be prevented mostly by the direct, instant feedback digital camera’s provide.