[VPM] database frontend

[Peter Scott]

At 11:34 AM 3/18/03 -0800, nkuipers wrote:
>Fellow Mongers,
>
>You've seen me progress through various stages with my project and Perl, and
>now I'm at a new stage.
>
>I've got a Postgres database with about 20,000 entries from the salmonid
>genome project, mined from about 80,000+ sequences as being 
>significant, by my
>Perl software. The database is very very simple at this point. What I need to
>do is throw up a correspondingly simple but effective web frontend for
>querying. I did a supersearch at PerlMonks on "database frontend" and from
>this I extracted the following tools for doing this:
>
>o CGI
>o DBI/DBIx::HTMLinterface
>o HTML::Mason/HTML::Template
>o LWP
>
>as well as the book "Programming the Perl DBI" (which I happen to 
>have). There
>were less than 30 threads in the sections I searched, and the relevant ones
>were from around 2001 (and dealing with MySQL, although I wouldn't think this
>matters). Are these tools (other than DBI/CGI, I would imagine they are
>involved) still the defacto standard? I've never done anything like this,
>including zero LWP or CGI experience. What are your suggestions? Any ideas
>welcome.

I would be interested in solutions here too.  I have done a lot of 
rolling my own in this respect, including my latest project whose back 
end database was a Remedy trouble ticket system.  What you appear to 
want is something like a ColdFusion capability, at least, that's 
something I was thinking about recently, after noting how easily CF 
integrates web forms and databases.

The only culprit I know for sure that does this integration is AxKit, 
although from what I've seen of it, that would be like using an atom 
bomb to crack a nut for anything short of a site like a Microsoft bug 
report tracking system.

What I do so far is just ensure that my database columns have names 
that I can also be used as HTML form input names, then when I read in a 
form I can pass param() through a routine that extracts values as a 
hash and returns it to an object constructor.  That part's easy; I 
never have to mention fields explicitly unless they're 
exceptional.  Unfortunately it's all the exceptions that are 
cumbersome.  Fields that need special validation, fields that need to 
be transformed, computed fields, and fields that go into records in 
another table.  Although frankly, probably a lot of the time just goes 
into creating the HTML.

You might look at Tangram and Alzabo (should be on CPAN).  They both 
map objects to RDBMSes.  One can handle legacy databases, the other 
requires you use it to create the tables.  Both are pretty complicated 
systems but you appear to have a knack for picking things up quickly 
:-)  Hard to say whether this isn't overkill for your application, though.


--
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com/