matthewb has asked for the wisdom of the Perl Monks concerning the following question:
Monks and mongers,
Time and again, I find myself bored silly producing XHTML forms to perform some piece of business logic which is, to some extent, coupled to a database. Indeed, so common is this requirement that I'm pushed to think of a project I've been involved in that didn't involve such an interface at some point.
“Laziness, impatience, hubris...”, we echo but how to be lazy, here? I'm getting impatient.
Solutions exist that purport to solve this problem through the auto-generation of semi-intelligent forms. They appear feasible because it's a problem that sounds like it should be solvable.
I've previously noded my frustrations with Class::DBI::AsForm; I've worked with and tried to like FormBuilder but find myself feeling that something is not right. I'd feel comfortable knowing that information pertaining to the database (model) is closely coupled to it but at what point do we feel that form generation becomes display logic?
And anyone who has done web development beyond the one-man pet project will know that it inevitably involves a graphic designer whose principal skill seems to be devising convoluted means to defy your generated forms. A similar frustration is that requirements are so often more complex than simple CRUD.
I'm looking for a generic and reusable solution that, critically, is not more work or less flexible that making a library of Template Toolkit forms and being done with it.
Naturally, I was interested in [id://merlyn]'s remarks the other day concerning the storage of column meta-data in a config file accessible through your Class::DBI-derived classes. Seems like a good idea and I hacked around with it that evening on a test machine. I've seen similar solutions using a database table to store meta-data before. But what meta-data to store? XHTML tag for representation? XHTML attributes? Default value? Order to appear in? User permissions? Would it be a good idea, taking the example from Class::DBI::AsForm, to somehow return HTML::Element objects for easy manipulation within templates?
And then, of course, it hits you: you've gone and defined a mini-language that does the same thing as XHTML just without being as easy to edit in emacs.
I'm interested in a general discussion on best practice and other people's experiences in this area; what are the gurus among us doing that I'm somehow missing?
Update: <readmore>s requested by [id://tlm]. I marked this OT originally because the problem is not specific to Perl. Thanks for all the replies. MB.
MB