January 2013 Archives

Form Rendering: Why Do We Even Bother?

Over the holiday I decided to do some development work even-though I had promised myself I wouldn't work on any open-source projects until all my commercial projects were completed.

I was bored, and since the alcohol and party-favors had lost there seductiveness, I thought I might revisit my super-secret-open-source-software-todo-list (we've all got one). I was looking for something complex enough to hold my interest yet simple enough to implement or at-least get a proof-of-concept out.

Since I've been doing a bunch of work on Validation::Class lately, I decided to work on an idea for a form field rendering plugin. First I'd like to exclaim, "I hate all-inclusive-html-form-handling-libraries", maybe not hate them but I strongly disagree with the premise upon which they are built.

Validation::Class::Plugin::FormFields is a plugin for Validation::Class which can leverage your validation class field definitions to render HTML form elements. Currently, the plugin is intentionally lacking in sophistication in an attempt to take as few liberties as possible (taking liberties is what makes most form renders suck).

Validation::Class::Plugin::FormFields is not an HTML form handler, nor is it an HTML form builder, renderer, construction kit, or framework. It merely renders a single HTML element at-a-time with as-little-markup-as-possible using the state of the associated validation class to maintain the state of the HTML form field.

Why render fields individually and not the entire form? HTML form handling is a heavily opinionated subject and the following reflects my opinion. HTML form rendering (done literally) has too many constraints and considerations to ever be ideally implemented. Consider the following; It's been tried many many times before and there are many different libraries as a result; It's never done quite right; There are too many conflicting contexts (e.g. css, js, security and identification, etc), i.e., CSS wants the form configured a certain way for styling purposes, JS wants the form configured a certain way for introspection purposes, the APP (and possibly the form renderer) wants the form configured a certain way for processing purposes, etc.

So why do we continue to try? "HTML forms are like werewolves and developers love silver bullets"(tm), but bullets are actually made out of lead, not silver. So how do you kill werewolves with lead? Protip, not by shooting them, obviously. I'd argue that we never really wanted complete form rendering anyway, what we actually wanted was a simple way to reduce the tedium and repetitiveness that comes with creating HTML form elements and handling submission and validation of the resulting data. We keep getting it wrong because we keep trying to build on top of the same misconceptions.

An HTML form is predominantly a UI by-product, and in large organizations (especially those which have segmented UI/ENG development teams) an HTML form and it's structure, layout, and markup are typically determined by the UI developers. Many HTML form renders are not viable simply because they impose UI decisions or require to much engineering to conform to the UI specifications.

So maybe we should backup a bit and try something different. In my opinion, the generating of HTML elements individually is much less constrained and definitely much easier to implement.

About Al Newkirk

user-pic ... proud Perl hacker, ask me anything!