Re^2: How to go about accessing differing database table requirements with out rewriting perl code.

It is a web based script, with limited administrative access based on LDAP group authentication using apache. Mysql accessed via DBI. Only a couple of tables. Mostly I wish to make it easy for me to deploy this for different groups who have different storage requirements. In the DB we store information about people who are on call. The script is mostly used to provide a single integrated front end to 2 different paging systems. The main issue is that I would like to define this in one place to effect, DB fields, html forms, and other stuff. Instead of having to edit a whole series of subroutines to make s

Comment on Re^2: How to go about accessing differing database table requirements with out rewriting perl code.

Replies are listed 'Best First'.
Re^3: How to go about accessing differing database table requirements with out rewriting perl code. by pajout (Curate) on Oct 20, 2005 at 15:25 UTC
If I understand you correctly, you wish the universal CGI script, which is able to update (and insert or delete?) records into different db tables and is able to provide various html GUI (forms with inputs logically related with db columns)? I am not experienced with CGI and MySQL, so I don't know, if some free codes are available on the Net - I work under pure mod_perl against PostgreSQL. But I can imagine some generic script using configuration file. I guess that the configuration must be very declarative, to describe tables, their columns, what can be edited under some conditions, etc. And I don't know, if it is effective for you to develop generic script and write amounts of configurations after that... I typically write one subroutine for one editor (== one html page), which calls generic subroutines, symbolically sub getHTTPQuery($request), sub doSql($dbh, $sql, $binds), sub sql2xml($dbh, $sql, $binds), sub responseFromXslt($xml,$xsl). This editor's subroutine realizes application logic: analyzes query pieces, does proper sql's, chooses proper xsl templates, does xslt transformation and returns it's html output. Some of them can be stored in configuration file, some of them can be hardcoded. My experience is that real requirements are too various and it is not effective to develop generalized editor subroutine.	[reply]

Replies are listed 'Best First'.

Re^3: How to go about accessing differing database table requirements with out rewriting perl code.
by pajout (Curate) on Oct 20, 2005 at 15:25 UTC

[reply]