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.

5 Comments

I totally agree, HTML form rendering is one of those area where an general 'one size fits all' solution is doomed to fail, regardless of its level of complexity (that some people call 'flexibility').

When I say fail, it doesn't necessarily mean they fail to get the job done. But to my knowledge, they always fail to be as easy and flexible as they claim to be.

In my view, I find myself much more productive with a 'toolkit' approach, where I can compose my forms from different abstraction level elements that are independent enough to play well with each other.

Hi Al

Hmmm. Did you mean Regex/p/::Common?

I support the general idea. There are so many modules in the area I dread the thought of reviewing them, in the Neil Bowers style.

See
this overview.

But I fear we couldn't manage with a system designed to be too minimalistic. For example, some fields need another plugin to add jQuery stuff to support AJAX.

So it goes.

Still, the idea is commendable.

Cheers

Hi Al

There is no such module as Regex::Common. You meant Regexp::Common. It's a bug :-).

laptop:~/perl.modules/Local-Novels$ cpanm Validation::Class::Plugin::FormFields
--> Working on Validation::Class::Plugin::FormFields
Fetching http://www.cpan.org/authors/id/A/AW/AWNCORP/Validation-Class-7.900013.tar.gz ... OK
Configuring Validation-Class-7.900013 ... OK
==> Found dependencies: Regex::Common
! Finding Regex::Common on cpanmetadb failed.
! Finding Regex::Common on search.cpan.org failed.
! Finding Regex::Common (0) on mirror http://www.cpan.org failed.
! Couldn't find module or a distribution Regex::Common (0)
! Bailing out the installation for Validation-Class-7.900013. Retry with --prompt or --force.

Leave a comment

About Al Newkirk

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