A Wicket Diary

While perusing a series covering a business model based on the Amazon S3 software service I came across the following quote:

Outsiders do not realise how deeply technological development, like scientific research, is shaped and driven by emotion. [...] The reason that half of us are in computing at all is that we see computers as things that we can make beautiful things out of

And that really sums up my emotion when I am building creating software.

The Wicket framework is adding animation (effects) support to its capabilities. Instead of reinventing the wheel we are looking at different libraries. Our list of requirements is not that big:

• the footprint of the library should be small
• the philosophy of the library should be similar to Wicket’s
• the library should enable most if not all effects available in most popular libraries
• the code should be clean and work in all modern browsers
• the library should play nice with the leading javascript libraries such as prototype, scriptaculous, dojo, jquery and Yahoo! ui

Now not a very impressive list, but apparently enough to drop scriptaculous and dojo (too large), prototype (not an effects library, can enable conflicts with scriptaculous, rico and others). I haven’t got much experience with jquery, but it seems to cover too much for our taste: we don’t need a full stack Ajax framework (already have that in place), but merely the animation part.

So that leaves Yahoo! Animation and … animator.js created by Bernard Sumption. I discovered animator.js when it was first featured on ajaxian.com and added it to my list of things to check out. Recently I was looking at some effects for our application and wanted to remove dependencies left over from the time Wicket didn’t support Ajax out of the box. Currently we have superb Ajax support and are now ready to take it to the next level.

I already had created a proof of concept, “I’m jealous of the Scriptaculous front page design”, new front page for Wicket. I made my first cut using animator.js and wanted to see how much work it would be to build it with Yahoo! Animation. So I spent a day to rewrite it using Yahoo! and tried to tweak the animation a bit to make it smoother.

You can see the animation on my people.apache.org page (links provided below). I have tried the animations using Safari and Firefox (1.5 and 2.0) and it led me to the following conclusions:

• safari’s javascript is horribly slow
• firefox’s javascript is extremely fast (compared to IE and safari)
• I hate writing javascript
• Yahoo’s event model is a bit more advanced than animate.js, somehow it looks smoother
• Animate.js seems to deliver more snappier animations
• I hate writing javascript

Try the animations yourself and don’t limit it to one browser. Comments are welcomed and appreciated. Press the back button to return here and select the other animation:

• Wicket homepage using Yahoo! Animation
• Wicket homepage using animator.js

Enjoy!

The last couple of weeks have marked the end for the Wicket trunk (formerly known as wicket 2.0, constructor change etc.). With a simple

rm -rf /Workspaces/wicket-2.x

I removed my local working copy of the effort. I imagine such commands being issues more frequently when we have backported most, if not all features from trunk into our 1.x stream. You can track the backports here.
So long, farewell, auf wiedersehen, adieu!

Is the MySpace digg.com clone going with the Wicket framework? I know the original founders of Newroo were Wicket users and their business proposal was built using Wicket 1.1. Given that they allegedly sold the company for $7 million to News Corp, that would be the most expensive Wicket application I know.

As MySpace is the worlds biggest website (according to TechCrunch), this would be a nice boost to Wicket’s fame. If only because their first prototype in Wicket gave them enough credibilty to get noticed and acquired.

BTW, they are hiring and want some Wicket talent:

Software Engineer

Fox Interative Media — FIM Labs/Newroo Project

Fox Interactive Media (FIM), a start-up division of NewsCorporation, is seeking a Software Engineer or Senior Software Engineerto work on a series of dynamic and innovative projects.

FIM Labs designs and develops new products for the FIM Network ofwebsites (MySpace, IGN, Scout, etc). The Newroo group’s main focus ison social interaction and communication around user’s personalinterests relating to news. The group is fast moving and highly focused.

Required Skills:
- Java developer experienced with large-scale web development
- Able to pick up new technologies and frameworks quickly
- Experience with POJO frameworks, in particular Hibernate and Spring
- Familiar with social software, blogs and similar technologies
- Works well independently and with a small, intense group
- Internally motivated to help create products with maximum impact

Skills that would be desirable, but not required:
- Familiarity with Wicket web framework
- Experience with web crawler systems
- Math/statistics background
- Knowledge of text processing and parsing
- Familiar with Lucene

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.