Aug 302006

I’ve been having a good discussion with some ACEGI users about my patch for AJAX and ACEGI. There are a number of other solutions out there and some contention about redirects and AJAX. The W3C specification for the XMLHttpRequest states that all browsers must support redirects transparently. Here’s the link:

The specific section is:

“If the response is an HTTP redirect (status code 301, 302, 303 or 307), then it MUST be transparently followed (unless it violates security, infinite loop precautions or the scheme isn’t supported). Note that HTTP [RFC2616] places requirements on UAs regarding the preservation of the request method during redirects, and also requires users to be notified of certain kinds of automatic redirections.”

So, I was asked by someone to mock up an example that illustrates redirects working with AJAX and here it is:

Aug 302006

I read this weeks JavaLobby newsletter and I noticed another post by Shai about JDK 5 features. More of a rant than a post about how the JDK 5 features suck and all that. I disagree that the features suck but agree the implementation is lacking. JDK 5 could really have done some wonderful things with the JVM if they choose not to use erasure for generics, but that’s my only main gripe. Other than that I think most of the features are fine. I use most of them and enjoy them a lot.

One thing he mentioned was that enums were a bad idea. He didn’t give solid claims as to why they were and asked for folks to post why they were a good idea. I’ve done some posting on enums in the past and I figured I’d take a stab at it.

Let’s think objectively about enums. I haven’t really done this to this point and my previous posts had a bit lacking because I forgot this step. What are they trying to accomplish? Model a fix set of values that does not ever change, right? Why a fixed set? First and foremost because without a fixed set a whole suite of problems arises including the serialization issue I discussed in this post. Adding new enum values is not backwards compatible. Let’s walk through an example.

Example: axis (3D axis)

Axes are a fixed set and could easily be an enum. What’s the JDK 1.4- solutions? Flyweight, ints, and Strings.

Okay, here are the issues with these:


  • These are pretty much the same as enums if they are final and have all the extra methods
  • In fact you could create static values and you have a type-safe enum JDK 1.4 style
  • They are serializable, fixed, and can have additional functionality added to them


  • Require a static somewhere to store the mapping (public static final int Y_AXIS = 1;)
  • Not type safe because methods that use the enum must take ints. If X_AXIS = 0, Y_AXIS = 1 and Z_AXIS = 2 I can still pass a method 42
  • You can’t add functionality without a helper class – like converting them to strings or looking them up by strings or whatever
  • If you encapsulate the constants and helper methods into a single class, you’ve almost made a type safe enum and might as well finish the task and get the type safety


  • Same as ints and they can’t be compared using the enums natural ordering without additional methods, harder to compare for equality

Okay, so if you abide by the contract of enums being a fixed set, I’m not sure I see the issue. You shouldn’t be able to sub-class them (that would make them NOT a fixed set), you can add functionality, compare them, they are type safe, can have additional attributes, which only the fly-weight solution from JDK 1.4 shares, and they can be compared directly.

I’m interested as to what the major objection to this is? If it’s that it is more syntax to an already complex language, than it really has nothing to do with enums but more the syntax of JDK 5 as a whole. If it is anything else, feel free to leave me comments. I’m very interested to hear what people feel is wrong with this pattern. Oh and stating issues when enums aren’t fixed sets is probably not a good idea. I know there a lots of issues with non-fixed set enums, but that’s a modelling problem, not a problem with the language construct.

Aug 262006

I’m always having ideas about the syntax, structure, APIs and everything else for the yet to be named IAL. So, I’m going to post my thoughts and let everyone give feedback. This will help shape things better in the long run.

I really want a mechanism so that a component can grab styles from an external location that is reusable. Something like a pointer to a look and feel element. This would be really nice in CSS and is possible, but requires each HTML element to define a class, which sucks. This would be better suited to be contained in the CSS:

Aug 152006

Bluprints 0.4 is released. The website has a lot more information about how to use it and it also has the JavaDoc available for those that want to code directly against the API.

This release has a bunch of new features including namespacing and multiple files and much more. You can read up about it at the project page

I’m still completely astonished at how simple this API is and yet how powerful it is. PLUS there are still no dependencies at all. This means if you want to use it in a web application, just drop in the JAR file. The XML parsing is done via SAX and the entire project is probably only a few hundred lines of code or so. We haven’t had any exceptional cases in production using it as compared to the random 10 exceptions a day we got from Tiles. Overall this is just a rock solid framework with good test coverage and lot of great features. Plus it gets the job done and is really simple. Anyways, enough raving. Enjoy version 0.4.

Aug 122006

I stand corrected with respect to the SubVersion support. I did go to the second page previously, but can be slow at times and the page did not completely load (honestly), so I assumed the option didn’t exist. Here’s a snapshot of the option:

SubVersion option

But, since I had been monkeying around with it so much, I think I broke it. When I tried to sign up with the same project name I had previously been testing I got this really nasty error message:

Error message

This project is already hosted at SourceForge, so I won’t be moving it, but this error message definitely is a bug considering if you do a project search, no project exists with the name bluprints. None the less, I’m looking forward to how CollabNet and SourceForge and Google Code start competing. I know that Google claims it doesn’t want to detract from SourceForge, but I’m hoping that Google Code at least forces the issue on CollabNet and SourceForge that their model is horribly inefficient and cumbersome. We’ll see. I’m excited.