Re: Mod_perl Application Development
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
RE: Mod_perl Application Development
Greetings. People often seem to get bent out of shape about putting a few Location directives in httpd.conf, I suspect that it may be due to the intimidating length that httpd.conf has reached in these times. I found that separating customizations in breakaway 'Include'd .conf files - and putting all my Include-s at the end of httpd.conf makes maintainence much easier (and upgrading apache relatively painless even under RPM's .rpmnew thing). Having Location directives [...] etc. without inventing your own config system. Warmly seconded. Cheers, alf
Re: Mod_perl Application Development
On Sun, 18 Aug 2002, Jonathan Lonsdale wrote: Here's a few approaches I thought of: In a previous life[1] I made a system that was configured like perl my $site1 = new Foo::Site(site = 'www.example.com'); $site1-register_handler( new Foo::ImageHandler(path = '/images/', format = 'png'); ); $site1-register_handler( new Foo::SomeOtherHandler(...); ); ... /perl VirtualHost ... PerlHandler $site1-take_request /VirtualHost (it wasn't quite like that; the site configurations were all in Perl modules dynamically utilizing perl_sections to configure Apache). When running register_handler, the Foo::Site object would call some method on the Handler object to figure out which namespace or which requests it wanted to handle. During take_request it would then just dispatch the right handler. This made it really easy to activate a subsystems when the customer needed them. The system also made it easy to customize the handlers for each customer. (Just inherit the base Foo::BarHandler into Customer::BarHandler and add the extra magic). - ask [1] okay, not quite a previous life; but it is more than 4 years ago. :-) -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: Mod_perl Application Development
On Sun, Aug 18, 2002 at 12:31:03AM +0100, Jonathan Lonsdale wrote: I'm curious to know how people approach application development with mod_perl in situations where there could be dozens of distinct screens/interfaces. I'm currently using the HTML::Template system. When using HTML::Template, I've found its query() method useful to tell the controller what code to call to pass data back to the template: http://perlmonks.org/index.pl?node_id=150608 Tom
Re: Mod_perl Application Development
Jonathan Lonsdale wrote: 2. Distinct content handlers each with their own Location directive. Could be a pain to maintain the server config. 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. - Perrin
Re: Mod_perl Application Development
On Sun, 18 Aug 2002, Jonathan Lonsdale wrote: Date: Sun, 18 Aug 2002 00:31:03 +0100 From: Jonathan Lonsdale [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Mod_perl Application Development I'm curious to know how people approach application development with mod_perl in situations where there could be dozens of distinct screens/interfaces. I'm currently using the HTML::Template system. Here's a few approaches I thought of: 1. Single monolithic content handler. Could be hard to maintain. 2. Distinct content handlers each with their own Location directive. Could be a pain to maintain the server config. I've usually done #2, and it is a pain. When you're developing and making up just one Location at a time, it's not so bad, but when you go to distribute the application and you see that someone will have to set up 10 or so or them, then it looks a little hacky. I've considered going to #1 and using CGI arguments (e.g., page=foo) or path_info (e.g., /my_handler/foo) to dispatch to the correct module. I certainly wouldn't advise that the logic for all these Locations be in one module. 3. Take a small performance hit and use an Apache::Registry script for each screen to handle the content phase. Use 'PerlSetupEnv Off', $r and Apache:: modules and don't bother being backwardly compatible with CGI. There's nothing wrong with this or just about any other way you can think as long as it works properly for you. I'm currently looking at the new Apache::TT2 module (http://apache-tt2.sourceforge.net/) as a way of getting rid of all Location directives. The templates are called in the same manner as HTML pages (i.e., by specifying a URL) and Apache::TT2 processes the pages as it normally would, allowing you to call out to objects and libraries and such. The exhaustive list of how other people are doing this would be difficult to compile and voluminous. I'd recommend you also look into all the other very fine application frameworks, like HTML::Mason, CGI::Application, Apache::PageKit and others. ky
Re: Mod_perl Application Development
On Sat, 2002-08-17 at 19:31, Jonathan Lonsdale wrote: I'm curious to know how people approach application development with mod_perl in situations where there could be dozens of distinct screens/interfaces. I'm currently using the HTML::Template system. Here's a few approaches I thought of: 1. Single monolithic content handler. Could be hard to maintain. 2. Distinct content handlers each with their own Location directive. Could be a pain to maintain the server config. 3. Take a small performance hit and use an Apache::Registry script for each screen to handle the content phase. Use 'PerlSetupEnv Off', $r and Apache:: modules and don't bother being backwardly compatible with CGI. There's a separate one that's used in OpenInteract: create a single content handler that uses some sort of lookup table to map requests to handlers. This lookup table can be maintained separately from the apache configuration and can generally be more flexible, allowing for application-level security settings, etc. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Mod_perl Application Development
Chris Winters [EMAIL PROTECTED] wrote: On Sat, 2002-08-17 at 19:31, Jonathan Lonsdale wrote: I'm curious to know how people approach application development with mod_perl in situations where there could be dozens of distinct screens/interfaces. I'm currently using the HTML::Template system. Here's a few approaches I thought of: 1. Single monolithic content handler. Could be hard to maintain. 2. Distinct content handlers each with their own Location directive. Could be a pain to maintain the server config. 3. Take a small performance hit and use an Apache::Registry script for each screen to handle the content phase. Use 'PerlSetupEnv Off', $r and Apache:: modules and don't bother being backwardly compatible with CGI. There's a separate one that's used in OpenInteract: create a single content handler that uses some sort of lookup table to map requests to handlers. This lookup table can be maintained separately from the apache configuration and can generally be more flexible, allowing for application-level security settings, etc. Yet another of the many ways : This is similar to what I am doing with the Uttu/Gestinanna projects. Gestinanna is designed around the MVC paradigm. I have Uttu provide my database/cache creation, application configuartion, and uri-handler mapping which in this case (for web applications with a lot of screens) maps to a Mason dhandler. The dhandler makes sure the proper state machine description is in memory and then continues the state machine execution based on the information sent from the client. The state machine tells the dhandler which view to send back to the client. I have several tricks up my sleeves to allow multiple state machines to be active simultaneously in a session and for even different parts of a state machine to be active simultaneously. I am using Template Toolkit to produce the views (since the people responsible for the views don't like code) and AxKit to generate the end result for the client (so we can support screen, tv, handheld, etc., media types as well as themes [we've had customers request this]). I haven't finished it all yet nor have I done any profiling, so YMMV. You can see the current code at http://sourceforge.net/projects/gestinanna/ (the PerlKB project will be worked in to handle documentation -- most of the current stuff in the Gestinanna project handles dynamic content instead of static content). Btw - I am looking at some of the various CMSs for `inspiration', including OpenInteract and Bricolage. I would recommend looking at how they do things if you are wanting to do content management. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
