software development in 2005

It’s really frustruating to write software, sometimes. Computers are exceedingly literal, and true abstraction is quite hard to come by. Adding documentation, written by wonderfully-silly humans,doesn’t always help, either.

For instance, Struts has a nifty feature for “map-based form properties”. Basically, if you write in your page:

<input type=”text” name=”nameMap(foo)” value=”bar” />

And when submitted, form.setNameMap("foo", "bar") will be called. Quite nice when you have a lot of dynamic content in the page and you’re trying to figure out how it needs to be related at form-submit time…

In fact most of Struts’ handling of forms is simple bean-addressing strings… you can create “nested” paths with ‘.’ (e.g., “person.name.first“), and do indexed properties with ‘[]’ (e.g., “names[42]”).

So, what happens when you want to use

<input type=”text” name=”nameMap( [ :name "joe bob"; :email "root@127.0.0.1" ] )” />

…? That’s an expression repressenting a single mapped-property call, with a string argument, right?

Ha Ha, no.

Turns out that the simplest thing that could possibly work here is to do String.indexOf() calls with the various delimiters. So the first thing that hits is the ‘.’ in the email address. Should that not have been there, the ‘[’ would be next up. Of course, neither are at all right. And, of course, in traditional programmer style, the documentation is perfectly willing to make believe that the expression syntax is robust and well-behaved.

A request to other programmers: any time your “parser” is based around calls to indexOf, then you need a big “THIS IS A HACK PARSER” disclaimer in your documentation, so people will give it this distance it deserves.

Update, a few minutes later:

It also does not help that the entire error you get when you make this mistake is…

HTTP ERROR: 500 BeanUtils%2Epopulate

RequestURI=/secure/dedup/un-c11n.spoke

…in the browser, and the misleading…

Caused by: java.lang.NoSuchMethodException: Property ‘namePerson’ has no setter method

…in the exception. Thanks, BeanUtils, for perhaps having the worst error messages evar.