>Jonathan Lonsdale wrote: >> 2. Distinct content handlers each with their own Location directive. Could >> be a pain to maintain the server config.
In my company we wanted an application which would make it easy to give users shared access to data that changed occasionally. The initial request was to move a weekly status reporting function from word documents submitted as email attachments from users around the world. These were manually compiled into another word doc. It didn't scale well, people often forgot the submission deadline or garbled the word template, and execs often wanted a mid-week snapshot, which was fairly impractical, as was comparing sequentiol status reports for follow up or action. We wanted a web interface, all data stored in a database, and a limited number of widgets to maintain. We created several handlers, each of which is for a particular "phase" of the application: one hanlder provides a CGI input/edit form. another handler an input verification screen, another for commiting changes to the underlying database. There also are several handlers for viewing the data in typical or interesting wasy: an audit handler shows all changes made against a given table record, a calendar handler for displaying date-based data on a month-at-a-time calendar view, a charting app, etc. The underlying data tables get properly represented onscreen by meta data stored in other tables in the database. The meta data provides information such as column labels, default sort order, number of rows to display on a page, which columns to show in the default view, how to manipulate the raw data (eg, with a perl subroutine.) For related tables we create a report derived (with perl subs) from columns of the underlying data tables. Now when IT receive a request for another web form, we CREATE the required data table(s) in the database, run an admin script to populate the meta data tables with reasonable defaults and the user can begin entering data. This process takes several minutes once we have agreed the data to be stored. We then modify the defaults as necessary; the time required for this varies depending upon the way the user wants data represented onscreen. >You would typically have a single handler that covers one "application" >with many screens, so instead of having an entry there for every >template you would have a just a small number of entries for >applications like a shopping cart or a message board. The applications >then manage which template to send out on each request using their own >internal logic. Things like CGI::Application and Apache::PageKit are a >formalization of this approach. > >People often seem to get bent out of shape about putting a few Location >directives in httpd.conf, but I find it simple to manage and like doing >this the standard way. Having Location directives lets you use all of >the normal Apache config options for access control, customized logging, >etc. without inventing your own config system. There are exceptional >situations (a requirement to add new handlers without a restart, for >example), but most people will be just fine doing it the old-fashioned way. We started with <location> directives in the config file but this became problematic as the number of tables got larger (>35) and occasionally tables had to be be deleted (eg, because a short term project ended). To reduce the administrative burden and the server restarts we created a ChildInitHandler à la Apache::Dispatch which determines the proper request handler to assign. Each URI includes the name of the desired data table plus the proper application phase, and any other query string data. We haven't seriously thought through the security implications of this approach, however the server is behind a firewall and all Internet access is via VPN. We recently posted the distribution with a demo database to SourceForge (<http://appwrap.sourceforge.net/>). The installation is make-based and pretty straightforward. The module namespace (Apache::AppWrap) should soon appear in CPAN. Best regards, Russell
