A Wicket Diary

This year’s resolutions:

• launch Wicket 1.3 (a vote is already under way)
• finish Wicket in Action (writing the last chapter on my list)
• revamp this blog, making it prettier
• work on Wicket again (writing took too much energy and effort)
• help out on the incubator lists, site and possibly mentor some project
• find out what the h*** an Apache Member is supposed to do
• have a blast when Eelco and Kay get married
• maybe loose some excess weight

I am the (currently not so proud) owner of a Logitech 250 USB headset that gives my patience a run for its money. Whenever I revive my Mac Book Pro (first generation core duo) and plug the USB headset into one of the USB ports, OS X grinds to a halt.

I’m not the only one who faces this problem. I can attest to the experience in that support discussion: it doesn’t matter in which USB port I plug the headset, or even if it is linked through my cinema display’s USB hub. The only thing I can add is that this happens when my mac book has been asleep.

Last time I complained on this blog about a thing that bugged me on OS X, it got resolved pretty quickly, so here’s hoping for us Logitech 250 owners!

Last friday I gave a presentation on Wicket at the awesome JavaPolis conference in Antwerp. Unfortunately I was only able to attend friday, which meant driving in early in the morning and delivering the presentation pre-coffee (the adrenaline rush is enough to keep an elephant awake for a week).

I had planned to spend about 20 minutes introducing Wicket and then spend the rest of the presentation working through a live example based on the Cheese store from Wicket in Action’s chapter 4.

I had prepared the live demo pretty good and knew how to complete it in roughly 25 to 30 minutes. The problem with live coding is that doing it standing up, in front of ~600 people and on a schedule is something different than sitting behind your desk. I had everything set up ready to go, but it is the little things that creep in to get you off guard. For instance having a phantom Java process claiming port 8080 when you want to start your demo, or having a too small a font for the Eclipse editors.

Though enough things went wrong, I remain convinced that doing a live demo is more enticing than watching a series of slides pass by. Nothing keeps a crowd more awake than seeing code actually work.

Tips for next time:

• Set a big font in all the Eclipse editors: 16pt or more. It is not good to have to modify this during your session.
• Make sure all Java processes are killed before the session starts, and then add those that you want. I had a quickstart session running from the evening before when my Eclipse crashed.
• Less history, more benefits of using Wicket, such as object oriented web development

If you want to see how the example should have turned out, I have uploaded the presentation I gave to slideshare. I have added the slides I had as backup just in case the demo would fail. This way you can see how it was meant to be.

| View | Upload your own

Not so long ago people complained about writing web applications being boring, not fun, or cumbersome. Though there is enough to complain about the Swing API (at least according to those that complain), it is generally considered to be a well thought out API.

So it is especially noteworthy when someone returns to Swing programming and longs for his web framework API. Ryan Sonnek writes:

I do miss Wicket quite a bit though. There are a lot of similarities between Wicket and Swing, but I think the Wicket API is much nicer.

In my opinion the message here is not that Swing has a bad API, or Wicket’s API is much better (this is merely the opinion of one coder), but rather that web development has come a long way, at least when you use Wicket.

One of my pet peeves is that library builders take special care to check for errors or exception conditions, but fail miserably to communicate what is wrong and how to fix it. The case today: json-lib (2.1).

I’m trying to use it to serialize a bean to JSON format and to compare it to a JSON serialized bean (it is easier to check text instead of the debugger trees). But the json-lib tells me that there is a cycle in the bean.

Caused by: net.sf.json.JSONException: There is a cycle in the hierarchy!
	at net.sf.json.util.CycleDetectionStrategy$StrictCycleDetectionStrategy.handleRepeatedReferenceAsObject(CycleDetectionStrategy.java:73)
	at net.sf.json.JSONObject._fromBean(JSONObject.java:658)
	at net.sf.json.JSONObject.fromObject(JSONObject.java:182)
	at net.sf.json.JSONObject._processValue(JSONObject.java:2426)
	at net.sf.json.JSONObject._setInternal(JSONObject.java:2447)
	at net.sf.json.JSONObject.setValue(JSONObject.java:1189)
	at net.sf.json.JSONObject._fromBean(JSONObject.java:725)
	at net.sf.json.JSONObject.fromObject(JSONObject.java:182)
	at net.sf.json.JSONObject._processValue(JSONObject.java:2426)
	at net.sf.json.JSONObject._setInternal(JSONObject.java:2447)
	at net.sf.json.JSONObject.setValue(JSONObject.java:1189)
	at net.sf.json.JSONObject._fromBean(JSONObject.java:725)
	at net.sf.json.JSONObject.fromObject(JSONObject.java:182)
	at net.sf.json.JSONObject._processValue(JSONObject.java:2426)
	at net.sf.json.JSONObject._setInternal(JSONObject.java:2447)
	at net.sf.json.JSONObject.setValue(JSONObject.java:1189)
	at net.sf.json.JSONObject._fromBean(JSONObject.java:725)
	at net.sf.json.JSONObject.fromObject(JSONObject.java:182)
	at net.sf.json.JSONObject._processValue(JSONObject.java:2426)
	at net.sf.json.JSONObject._setInternal(JSONObject.java:2447)
	at net.sf.json.JSONObject.setValue(JSONObject.java:1189)
	at net.sf.json.JSONObject._fromBean(JSONObject.java:725)
	at net.sf.json.JSONObject.fromObject(JSONObject.java:182)
	at net.sf.json.JSONObject.fromObject(JSONObject.java:145)

Very informative stack trace indeed.