Fussing with Forms (Part 1)

Back in the old days, you'd often see forms embedded within tables, so the following markup would be common:

Luckily, those days are mostly gone, but there are still different schools of though on the best way to mark up forms. Examples are a div based approach:

an ordered list

or the tighter (but harder to style)

(If you want to know, I'm quite partial to the ordered list - that seems to me a reasonable balance providing some more elements for getting the styling just right while still being meaningful and reading well in most screen readers.)

The problem is that if you're building an application with lots of forms you have to choose and type a specific type of markup for every single field and would have quite a job if you needed to refactor from (say) the second implementation to the third towards the end of a project with hundreds of forms and thousands of fields (I'm sure you could perform an XSLT, but I don't think it'd be a trivial process). But why are we tying ourselves to a specific markup implementation in the first place and repeating it with every single field when the same core intent could more simple be described as:

We might even be able to add simple conventions and for many of our fields just write:

Using a convention (for example - your convention might vary) that the name is simply the title with non-alphanumeric characters removed. Of course, you'd still have to have name as an optional attribute, but why repeat yourself for the many fields where some such rule could be formulated - especially on green field applications?

So, in this simple case (we haven't got into drop downs and date pickers and WYSIWYGs just yet), it is clear that a DRYer, more concise syntax would allow us to both create forms more quickly and refactor their actual implementation more easily. The question then is what would be an appropriate syntax for describing forms? There are lots of levels of explicitness or implicitness to choose from.

If you love XML, I think the answer would be clear:

A Pythonista might propose:

A minimalist might suggest that if a form was only comprised of fields (let's make that simplifying assumption just for now) then you know each row is a field, indentation tells you when the form has ended, and using implicit named arguments all you really need to enter is:

I'm a little worried by the minimalist approach as once you start to have more than a couple of arguments it becomes impossible to remember what the third parameter was, and the learning curve for such "as long as you know it, it makes sense" interfaces can be steep (I know - I wrote a couple of applications that way and even *I* find it hard to remember what all of the parameters were for some of the method calls without having to open up the appropriate beans and check their method signatures).

As for the difference between the XML and Pythonesque approaches (primarily a tag vs. a method call style syntax with the added twist of meaningful white space in the Pythonesque sample to save the brackets or end tags that would otherwise be required to denote the end of a semantic block), firstly I don't see much of a difference. OK, my heart stirs a little stronger at the "cleaner" code which is able to use a few less characters to encode intent, but both of these are DRY - unlike the earlier example, they aren't repeating redundant markup information with each field (whether it's in table cells, divs or an ordered list), so I really don't care that much. Especially as it would be very straightforwards to write an automated transformation to turn one into the other. Because of that, I'll just see which would be the easiest for me to implement.

So, to summarize, I've taken the example of a simple form and noted that we are often repeating information that we may need to refactor relating to the markup of a form. To be honest, as I step back and review this posting, I'm not sure that I ca justify the overhead of a generator for the amount of information I'm saving. I think if this was the only issue with forms, I'd be tempted just to select a markup (probably the ordered list) and to stick with that, arguing against refactoring to a different style of markup unless it was really essential for a given project. However, I have a feeling that I may get a few more wins by generating my HTML either from XML or from method calls, so I'm going to take the thought experiment a little further and see what shakes out. In the next posting I want to look a little more at some of the other information that would be required to fully describe a real world form.