A Wicket Diary

Why is the current state of subversion integration into Eclipse so lousy? Subversion is a viable platform for quite some time now (I know I have been contemplating moving to SVN 2 years ago).

Subclipse checkout of our Wicket project doesn’t show up in the package explorer, I had exception reports in Eclipse, a checkout that didn’t do jack. Now I try to check out the wicket project, but still I get strange hangs in Eclipse. For some reason Subclipse thinks that my wicket project is still in my workspace, and wants to delete the directory. I let it do that, and then it starts deleting each file where it takes 15 seconds for it to discover that the file isn’t there. This is killing me!

The fairly new Subversive plugin also does a bad job of working as a stable plugin. Granted they are in development mode, but why can’t I compare my current version of a file with a previous revision, WITHOUT eclipse hanging itself up the trees? Why do I have to choose the revision in a MODAL dialog, instead of the CVS view?

Also, subversion really is DOG SLOW when browsing the repository on sourceforge.

I’m shocked that Eclipse, the most used and popular IDE doesn’t integrate with Subversion the way it does with CVS. It is appalling.

A nice Web 2.0 quiz which tests your knowledge of Starwars characters and Web 2.0 products, frameworks and tools. They cateogorized Wicket wrong! Not only is Wicket a furry, ferosious Ewok but also a web application framework quite suitable for web 2.0-ness.

So in my opinion, the radio button should be a checkbox, and you should get a bonus for having both correct!

PS. my score was 34. It should have been 35, if they had given Wicket the correct score. Thanks KJB, for pointing me to this quiz!

Dojo is one of the best, most used and most popular AJAX and JavaScript toolkit out there. They have brought software engineering to the browser space, and I applaud them for it. There is a downside to it though.

Because Dojo wants to do everything, it is huge. It requires its own build system and one dojo.js file is possibly quite different when compared to another. As a framework user, I just want the .js file, include it and start using the thing. With Dojo that is not how it is done. Either you assemble your own dojo.js, and from there start using it, or include the bohemoth 150kb JavaScript file.

I’m not against downloading that 150kb, nor am I afraid that any of our customers might notice the download. It is only done once in the session, or when you set your headers correctly, once per day or even week. Most of our applications get deployed on corporate intranets, so the delay is hardly noticable.

This is all understandable and workable. I’m not a fan of assembling my own thing, so I just use the standard Ajax distribution and be done with it.

The build process and packaging of the dojo.js library is also its downside. It is impossible to actually debug anything inside a packaged dojo.js. And worst of all, a packaged dojo.js file still tries to include external files. The whole idea of a packaged dojo.js file is that it is standalone. Yes most browsers will ignore the missing files and continue as advertised, but on OS X, Safari stops evaluating JavaScript code when __package__.js files are missing. Why does dojo want to include those files? Here is the list of files, files marked in bold are reported missing.

• file:///wicket-examples/src/java/wicket/examples/preview/__package__.js
• file:///wicket-examples/src/java/wicket/examples/preview/behaviour.js
• file:///wicket-examples/src/java/wicket/examples/preview/dojo.js
• file:///wicket-examples/src/java/wicket/examples/preview/Home.html
• file:////wicket-examples/src/java/wicket/examples/preview/login/Login.html?dojo.transport=xmlhttp&
• file:///wicket-examples/src/java/wicket/examples/preview/src/__package__.js
• file:///wicket-examples/src/java/wicket/examples/preview/src/io/__package__.js
• file:///wicket-examples/src/java/wicket/examples/preview/wicket-preview-behaviour.js
• file:///wicket-examples/src/java/wicket/examples/preview/wicket-preview.js

So what is the one thing I don’t like about dojo? It is just too damn complex.

Karthik Guru has written Wicket Ajax article on his blog. This time concerning an Ajax autocomplete example using Wicket Extensions (1.2-beta2).

Matt Raible has asked the leading web framework authorities about their frameworks and to comment on other frameworks as well.

• JSF, Jacob Hookom
• RIFE, Geert Bevin
• Seam, Gavin King
• Spring MVC, Rob Harrop
• Spring Web Flow, Rob Harrop and Keith Donald
• Stripes, Tim Fennell
• Struts Action 1, Don Brown
• Tapestry, Howard Lewis Ship
• Trails, Chris Nelson
• WebWork, Patrick Lightbody
• Wicket, Eelco Hillenius

The article is a pretty good read and gives a good sense of how the different developers look at the outside world, if they do so at all.