Blogging Pubbitch

I'm starting to write a simple plugin for Eclipse. This wouldn't be too bad except Eclipse uses modal dialogue boxes when setting up a new project. This wouldn't be bad if the eclipse help view wasn't opened in a window that's (for want of a better word) eclipsed by the "new project" wizard. This isn't so bad until you're trying to follow instructions in the help text that guide you on how to set up a new project and have to scroll down. Do you see where this is going? You guessed it. Try and scoll the help text down a bit to see what the next step is, and voila! Back to the "new project" wizard, none the wiser, but a little more irked.

The worst thing about it is that the help documents are simply webpages that are served from an internal instance of some app server (tomcat, I think) At least there's a way out of this modal hell....

Since my recent flirting with IDEA and subsequent fall from grace back to Eclipse 3M9 I've been working on learning some tricks to make development that little bit nicer.

First off, it's possible to store a project's source outside eclipse's workspace. It's an option when starting a new project; simply select "Create separate source and output folders" in the "new project" wizard. Easy.

One of the features that I really liked in IDEA was the ability to jump straight to a class by hitting "ctl-n" and starting to type the name. The key binding for something similar in Eclipse is "shift-ctl-t", though it shows every class within the project's classpath rather than just those you've been editing. Bah! To allow access to a random file, "shift-ctl-r" (for resource) does the trick. Better still, it's possible to declare the file name with a wild card ("*.xml" is handy)

M9 also offers the ability to create accessors and mutators from the "quick fix" menu (normally bound to "ctl-1") or the auto-completion menu (bound to "ctl-space") Simply start by typing "ge" in the place that the getter should appear, hit one of the shortcuts and select the appropriate entry from the menu. Obviously, using "ctl-alt-s" can be used to bring up the "source" menu in the editor, allowing you to create multiple getters and setters in one fell swoop. Better still, this completion of method names extends to allowing a class to over-ride methods from the parent class; just hit "ctl-space" in the body of a class and select away --- far easier than remembering the method signature!

Finally, one nice thing that can be done to speed up ant builds is to get eclipse to compile classes into the build locations specified by ant. That is, if ant normally compiles classes into "build/java" and "build/test" it's possible to configure eclipse to compile classes there too. It's done by going to the project properties, going to the "Source" tab and selecting "Allow output folders for source folders" It's then a (rather tedious) case of expanding each source folder and editing the "Output folder". Lovely. A build which was running up into the 30 seconds time frame is now down to a lowly 8 seconds, including running all the unit and integration tests.

I'm probably teaching a lot of developers how to suck eggs, but it was interesting for me!

Now, if only someone would create a Xerces plugin project for Eclipse the world would be a shiny, happy place....

When writing code, I like to try and imagine what would happen if someone unfamiliar with the code comes along and tries to understand why it works the way it does. I like to imagine that this someone comes along several months after the project is finished and doesn't have much of the original documentation to hand (for whatever reason) What's there in the code is what there is to try and understand the system.

This has a number of ramifications. The key classes within the system should really be documented adequately in the javadocs, and a list of these key classes should be available somewhere. Of course this "somewhere" could be as distributed as the web.xml file and the framework configuration files, but it should exist. Comments within the code should explain why particularly whacky things are done: no comment, no reason as far as the newbie to the code is concerned.

The other big corollary is that I shy away from using "magic numbers" When there's a choice between using some sort of number as a shorthand for a bunch of logic and writing that "bunch of logic", I tend to plump for writing the extra code every time. Why? Cycles are reasonably cheap, and it's unlikely that those few extra lines of code will slow performance by enough to make it worth optimising away. I can encapsulate the repetitive parts in a method, meaning that there really isn't that much more typing to do. And finally, someone who comes to the code fresh can instantly understand that the code takes a certain path because of clearly documented reasons.

If a magic number is simply unavoidable, I like to define it on the interface or class to which it is most directly applicable, giving it a sensible and descriptive name. "100" doesn't tell you much, but "Message.SALE" gives an far better indication of the meaning behind the number. More documentation is also a Good Thing.

Alternatively, I could always write some unmaintainable code and lumber myself with a job for life.

The project that I'm working on in the office could probably benefit from the use of a rules engine. It's not for sure, so I don't want to spend a lot of time looking around for something that might not be appropriate. Obviously, something that follows JSR 94 might be a wise idea: if the implementation that's picked isn't up to snuff, then it's easy to change to something else.

The first rules engine that I look at is Drools. Oh dear. The manual seems inadequate from a quick scan (I could be wrong: maybe what's there will be enough for me to get going) but what I really want are some examples: there's nothing like seeing a project in action to find out how easy or hard it is to use.

No go. Nada. Zip. Nothing. The section in the manual about "examples" is only as long as the title, whilst the binary distribution doesn't bother to include the examples that are included in the source tree I can see on CVS. Fortunately, I've got CVS access to the outside world because the IT folks were nice and punched a hole in the firewall for outgoing access. Unfortunately the build uses Maven, an inexcusable collection of bytes masquerading as software --- in all my previous encounters with it, it's either failed to work at all, or just been horrible to use. Frankly, I'd rather configure XF86 by hand than touch maven, but since my display is currently rock solid and accelerated after a previous near-miss with maven there's no other option.

I install maven. Well, I say "install", what I mean is "download and unpack into /tmp ready to be deleted at the drop of a hat". I get to the right directory and wonder what targets are available. Several screen fulls of text later, I decide that this is a silly idea. Perhaps the default target will do the Right Thing? It promptly does the wrong thing, and insists on downloading an older version of Drools from the Net, but at least at the end of that process, an examples JAR is produced. Now we're cooking.

Or not, as the case may be. There are no docs about how to run the examples, but a quick scan of the contents of the JAR suggest some likely candidates, and so begins the game of "complete the classpath" that Java likes to play. I get most of the way, but end up with an XML parsing error. At this point, I've had enough. The hat drops, maven gets wiped off my machine, as does drools. Maybe some other day. Maybe on some other project.

I'll get to it in depth later but for the record, OGNL's datatype conversion coupled with XWork's parmater setting is a lovely thing. I've just had the pleasure of ripping out a chunks of code that simply convert between Dates and Strings in java and replacing them with a simple, well tested "DateConverter" that can be applied declaritvely to my actions.

Very cool. For a "saved me a chunk of time at work" value of "cool".

Webwork is an MVC framework made by those nice people over at Open Symphony. It's Open Source and a doddle to learn. It's so easy, I'm going to introduce it to you over a series of blog entries. So, here goes nothing.

Before we begin, perhaps it'll be useful to know how all the bits and pieces within Webwork 2 fit together. Essentially, Webwork builds in web support for XWork, a generic command framework. XWork provides support for such pleasentries as declarative validation of content and the use of these things called interceptors (which I'll come to in another blog entry: for now, think "XWork Action is to Servlet" as "XWork Interceptor is to Filter" and you've got the idea)

So, XWork is basically an implementation of the Gang of Four's command pattern. The implementation rests on an interface called "Action" (or "com.opensymphony.xwork.Action" if we're being formal) which has a single method with the signature:

public String execute() throws Exception

When XWork calls this method, it uses the returned String to map to a view. How does that work? Simple. XWork uses a file found on the classpath called "xwork.xml" to configure itself (which means that in a web app, it'll often be found in WEB-INF/classes) This file, at it's most basic, looks like:

<!DOCTYPE xwork PUBLIC "-//OpenSymphony Group//XWork 1.0//EN" "http://www.opensymphony.com/xwork/xwork-1.0.dtd">
<xwork>
  <include file="webwork-default.xml"/>
  <package name="some-name" namespace="" extends="webwork-default">
    <action name="woot" class="fully.qualified.class.name">
      <result name="success">joy.jsp</result>
    </action>
  </package>
</xwork>

What does all this mean? Basically, it says that when a request for "woot.action" (because ".action" is often bound to execute XWork actions, as ".do" is often used in Struts applications) XWork should instantiate a new instance of the class "fully.qualified.class.name" and call the "execute" method. Should this method return "success", then XWork will forward (not redirect) the request to "joy.jsp".

For now, let's not worry ourselves about the "include" (hint: it includes another configuration file, in this case from the "webwork2.jar") or the "package" declarations (hint: it's a mechanism to logically group actions together) Instead, marvel at how the action tag contains one (or more) nested "result" tag(s). The "name" attribute of the result tag matches the return value of the "execute" method, and the contents of the tag point to the view that should be rendered. How easy is that? That's a rhetorical question, but the answer would be "pretty damn easy" if it wasn't.

One interesting thing to note is that each request creates a new action object. This has the handy side-effect of meaning that your action's do not need to be thread-safe, and because object creation is relatively cheap the effect on the system's efficiency isn't shattering. Which is nice.

Right, I better get back to my day job. You've got an idea of what XWork is and how it relates to Webwork, and how it routes to a different view depending on what the return value of the execute method. Next time, I'll go over actually packaging up a Webwork application so that it can be deployed with minimal grief. I might even tell you more about interceptors....

Over the weekend, I finally made the time to tidy up the SpringObjectFactory that I had made for XWork and add it to the xwork-optional project. It works with any release of XWork equal to or greater than 1.0.1 (which is currently in CVS)

So, what does it do? Currently, it can be used to pull actions and interceptors from the Spring application context, which allows XWork to make use of Spring's excellent IoC implementation, as well as powerful features such the aspect-oriented features that Spring offers (for instance, it's a doddle to wrap an action's execute method into a delcaratively marked transaction using Spring and XWork) The next step is to pull in some code to allow it to be used with the external entity resolvers that are out there. The example code is already in a JIRA issue, so it's going to be the matter of a few minutes work.

I love it when a plan comes together :)

When Java Blogs was new, I added my old blog to it. It's been a heck of a long time, but I've now added this one to it too in the hope that it'll encourage me to both write more and write more about Java.

During the week, I was given developer rights (writes?) on the xwork-optional project, and I've spent a little time today cleaning up the code for my XML-RPC dispatcher and view before adding it as a module to the project. It's up there now as "xmlrpcwork".

In a hopeless show of belated self-promotion, I should point out that about a month ago I had my first article published on ONJava. It looks at the various types of Mock Object out there, and how they might be used. If that sounds like something you'd be interested in, the article is here.