Author: Rory Winston

We have been doing quite a lot of Ajax-related work on our project recently. Writing rich-UI applications with a lot of client-side Javascript and Ajax-type functionality can be a chore, due to the lack of comprehensive debugging tools. However, there are some excellent Firefox plugins that make things easier, such as the Web Developer extension, TamperData (a more sophisticated version of the earlier Live HTTP Headers extension), and the sadly underdeveloped Venkman.

However, the newest and best extension is undoubtedly FireBug, which is like a one-stop shop for Web development tools. FireBug 0.4 has recently been released, and now has integrated JavaScript debugging support, which can be triggered by inserting a debugger; statement into your JavaScript code at the point where you wish to trigger a breakpoint. FireBug also has a very useful “Inspector” tool, which can be triggered by a CTRL-SHIFT-C keystroke, upon which any element can be selected, in order to display its source, DOM properties, and CSS styles.

Another useful feature is the console, which allows you to enter arbitrary JavaScript commands within the context of the current page, so if you are using Prototype, your $() etc. commands will work. One very useful feature in FireBug that I haven’t seen anywhere else is its support for Ajax request snooping. You can view each individual request (and response) within the FireBug UI. This extension has already been very useful, from debugging some awkward JavaScript, to debugging hard-to-find conflicts due to CSS precedence rules. I would recommend trying it.

Another strange issue with Hibernate Criteria queries…

Say you have a class Foo which has a one-to-one property mapping to a class to type Bar. The class Bar is a custom UserType implementation. The mapping might look as follows:

<property name="bar" type="uk.co.researchkitchen.usertype.Bar" column="bar" />

Now say you want to include this property in a Criteria query. Specifically, you want to query the property called name of the Bar class. As per the last pot I wrote about this, it seems logical that you would create a sub-criteria for the Bar property, and add an Expression on Bar.name, like so:


Criteria barCriteria = fooCriteria.createCriteria("bar");
barCriteria.add(Expression.eq("name", "TestName"));

However, this doesn’t work. Hibernate theows a QueryException with the message “not an association type”. Stepping through the code, this happens when Hibernate internally creates an instance of a CustomType class to represent the UserType property that we are querying. Hibernate checks if the class is a composite or association type (of which CustomType is neither), and throws an Exception if it isn’t. However, you can get this to work by using the Example functionality of the Criteria class, as follows:


Foo foo = new Foo();
Bar barType = Bar.getInstance();
foo.setBar(barType);
hibCriteria.add(Example.create(foo));

Quite why this works and the former method doesn’t, I don’t know. I haven’t had time to look at it in detail. At least for now, there is a (slightly non-intuitive) workaround.

I had a bit of spare time this weekend, so I revisited a project that I occasionally work on – the Jakarta Commons::Net project. From time to time, if my schedule permits (rarely these days, sadly), I’ll visit Bugzilla and try to fix some bugs. This time however, I had a feature to add – I needed support for a parser for a Novell Netware FTP server (truly a rarity these days, however the business school I am currently studying at uses it), and decided to add it. So after a couple of hours, I had a working parser implementation and corresponding unit tests.

Most of Apache these days has migrated from CVS to SVN, and the general comfort level as regards to SVN seems to have increased considerably. I decided to upgrade my (extremely) out-of-date copy of TortoiseSVN while I was checking in the changes. I was struck by a few things:

• TortoiseSVN (and Subversion, more generally) has come a long way. The menu has expanded quite a bit since I last used it, and there are a ton of new features in there. No doubt there are plenty of low-level enhancements that have been incorporated as a result of new versions of Joe Orton’s excellent Neon library, but there are also some more fundamental changes in there.
• Subversion, like CVS, follows the 80/20 rule – the 80% of operations that you will perform repeatedly are very intuitive and easy. This means that some more complex operations can be more fiddly, but most of the time, you don’t notice, because you don’t need them. I contrast this with ClearCase, which I am using at the moment on a separate project, and the difference is pretty stark. Where SVN is elegant, ClearCase is clunky, and where SVN is intuitive, ClearCase is confusing. Of course, ClearCase in its own right is very, very powerful, but it looks and feels like a 20-80% type of product.
• I used to have the odd “lock up” with SVN’s Berkeley DB storage engine (especially if a commit in progress got interrupted), which doesn’t seem to happen any more. The CVS-alike file system backend looks like it will probably be the way forward.
• There were traditionally some doubts about the scalability of SVN, but it hosts some pretty big repositories now.
• The merging/branching process is quite straightforward under SVN. TortoiseSVN even gives you the ability to do a “dry run” of the merge process before actually risking anything – very cool.
  

There are a couple of things that I’m not 100% happy with, and one is that SVN can’t seem to efficiently figure out how to retrieve a list of revisions for a particular file, so when you try to retrieve a revision graph for a specific file, it seems to want to traverse the revision tree for the entire repository. This results in TortoiseSVN telling you that it will take 5 hours to generate a revision graph! I guess this is the same issue that prevented a port of CVSGraph from happening. Hopefully they’ll sort this out.