Monday, 17 September 2007

More about why Java engineers should not code HTML

When writing JSP custom tags Java developers should avoid writing HTML attributes to the response. There are a lot of examples of this in Struts, but what prompted this post is special.

We had need to set autocomplete="off" in some secure forms using a custom tag written c. 2000. A seasoned Java developer felt this could be supported in the custom tag easily enough through a tag property.

Wait for it…

The new property was autocomplete. The property accepted two values: (true|false). This would of course be written then as autocomplete="false" if the desired output was autocomplete="off".


There are at least two problems with this: 1) it is completely unmaintainable, 2) it is useless. The former is more important than the latter.

Visiting this code for the first time I thought some HTML developer got the attribute wrong, setting false where he/she meant off. Instead, I learned that the custom tag used this as a property to produce the corresponding HTML form attribute autocomplete="off". Being a Java programmer, I actually looked at the tag class source code to figure this out; making my point that it is unmaintainable for most front-end developers.

My latter point is: why have this tag property at all? There is a concept of pass-through attributes in most JSP frameworks, like Struts, Stripes, even JSF. Even if the developer had to add this property, why change the standard—yeah, autocomplete is not W3C, but it is adopted by all major browsers for the form element (except Opera)—and just handle the values (on|off) in the tag class appropriately. It’s just like an engineer to actually use the HTML attribute, but change the value to use a boolean literal.

Then there are the Java programmers that confuse an HTML attribute with a JavaScript property... sorry dude, form.autocomplete="off" will not work. Ugh.

Posted by caffeinated at 10:35 PM in nerdery
« September »