Fussing with Forms (Part 2)

In the first part of this series I looked at how we could describe simple forms more concisely and DRYly. I'm not convinced that I made the case that a generator would be "the simplest thing that would work" - it all really comes down to how likely you would be to need to refactor your form markup during a project. Still, in this posting I want to look at some of the additional types of information required to describe a form to see if I end up with sufficient benefits to make it worthwhile to write a simple form generator that'll take XML or method calls and generate the appropriate HTML . . .

There are a couple of (very) small syntactic wins we could get with a form generator in terms of describing the form and hidden fields. Given that the majority of simple web apps use method="post", we could make that a smart default for a form thus making the method parameter optional and only used if you DIDN'T want "post". We could also tighten up the syntax for the many hidden fields we often use for managing state. So we'd take:

And would get XML like:

or method calls that might look like:

OR

Or if you're into writing parsers, a little language that might say:

which looks tighter but will suffer from the problems I mentioned in my last article as this is really similar to method calls using implicit method ordering and while removing the name= and value= cuts down on what looks like visual cruft when you only have two obvious parameters, it makes the code completely unreadable as you start to get more and more parameters (and un-implementable if there are multiple optional parameters which can't be reliably distinguished based on mutually exclusive allowable value sets).

Well, I think that is a nice example of looking at different ways to encode the same intent and some of the associated trade offs you make as a language designer when choosing a concrete syntax for your DSLs, but even with the tighter mark up for field names and the small savings in hidden field descriptions this still isn't really worth the effort of messing with.

Of course, we could add some nice little features to such a generator such as passing a struct/hashtable or even a bean into a form so if we wanted to keep a set of state variables we could pass it into a form using a single call rather than having to write a loop. Let's say we wanted to pass all items in URL scope into hidden form variables. Instead of having to write a loop to go through the URL scope we might just write:

Again, not bad, but not a big enough win to justify the effort of writing, documenting and learning the generator. However, I think we *may* start to get a win when we start to encapsulate the implementation of rich form controls and client side validation. I think that'll have to go in article three in the series!