About half a year ago the core Wicket team decided that we needed a radical new way of constructing our component hierarchies. This led to the infamous 'constructor change'. Basically this change requires you to provide the parent of your new component at construction time. The benefit is that the hierarchy for your component is available in the constructor, which opens up a lot of possibilities:

  • line precise error reporting in your Java files: can't find the component in the markup, throw an exception and you know exactly which component violates the hierarchy
  • markup attributes available in the constructor: you can manipulate the tag's attributes directly instead of using an AttributeModifier
  • functions as getPage() and getForm() work in the component's constructor, allowing you to generate JavaScript at construction time, instead of render time (the full path, and markup identfier are available at construction time)
  • ...

So we embarked on a journey that would define the future of our framework: Wicket 2.0 would be tha bomb, our own shark with frickin' lasers on top of their heads, not genetically mutated, bad tempered sea bass. However, the proof of the pudding is always in the tasting and it appeared that more things were harder and less clear to do.

By requiring the parent of a component at construction time, we 'fix' the hierarchy and reparenting components, moving them around across the page is really dangerous: what should you do with the markup attributes that are already set in the constructor? Suddenly you needed factories to create dynamic component structures instead of just adding the component to a list...

And if this is not enough, the change is such a major break that existing projects building on Wicket 1.x would never cross the 2.0 barrier. You'd have to rewrite your whole UI layer, which is not very economical. We already realized this, so we kept Wicket 1.x alive and kicking by backporting key features into that development stream. Basically we had 3 branches to keep alive:

  1. Wicket 1.2 (our current stable release)
  2. Wicket 1.x (head for Java 1.4 and pre-constructor change Wicket)
  3. Wicket 2.0 (trunk, using Java 5 and constructor change)

This severely slowed us down. Estimates are for about 25%, but I think it is closer to 50% or even 60%.

So when serious development with the 2.0 changes were done, the culprit that first came up with the change came to the conclusion that the benefits were not as great as the disadvantages.

In my opinion the biggest disadvantage is that we create a rift between the two versions, basically doing a 'Tapestry' on our users: changing the whole project between major versions.

When a project decides to completely change, then your users will also look around. If they have to change their application anyway, why not see if there is anything else, maybe even better?

Creating a rift in our community is really not good and therefore I won't veto discontinuing the constructor change.

We have discussed this change in direction for our framework the last couple of days, and need your input. If you have an investment in Wicket 2.0, then please let it be heard on our user list. We want to know that you use Wicket 2 (our trunk) so that we can use your experience in deciding whether to continue or not with our current roadmap, or that we need to discontinue the constructor change.

PS the Java 5 enhancements will be kept either way. We like them and think they are good for the framework. So if we decide to discontinue 2.0, we will backport the remaining changes in trunk to make the change as smooth as possible.