Speaking about the theory of this I was thinking about making a script that does something like:

Foreach field of the table fetch the field name, data type and length. Then generate the html tag according to this information.

I think this is quite easy to do.

As I say, it does sound like a solvable problem, this is the central premise behind Class::DBI::AsForm.

But this supposition breaks down quite quickly when developing applications for the typical (read:awkward) client. How can portability be maintained across DB servers? What about business-specific requirements for form fields such as something as simple as them wanting a <select> where a text input is implied by the schema.

Often you'll have a couple of TEXT fields, one of which they want to be really large for some reason. In a drunker moment I once set about hacking AsForm to read existing entries in TEXT fields and try to assign appropriate rows and cols attributes based on existing entries (!).

Look at how Maypole gets on going down this route: for all the hype about not having to type out your column names even the simplest application will require you to type them out three times to get anything resembling professionalism (to define the headings the user sees, the untaint rules, the relationships etc.)

The consensus seems to be what I feared but have always ended up with in the past - it's still less work and more maintainable just to make the things yourself and get on with something else ;)