thraxil has asked for the wisdom of the Perl Monks concerning the following question:

i've held off for some time now on using the CGI::Application framework for building applications. recently i decided to take a good hard look at it and i can definately see some merit to the idea. so i decided to port a few of my apps to it. i've encountered a few problems.

the biggest one, that i'm hoping someone else might have some useful insight on is that under mod_perl, using CGI::Application seems to trigger problems with HTML::Template.

i have a class Foo that is instantiated during the setup() routine and the instance is stored using the param() mechanism. Foo does a bunch of useful things including producing HTML::Template instances with some common params already set. so the typical usage looks something like this:

sub some_runmode {
     my $self = shift;
     my $foo = $self->param('Foo');
     my $template = $foo->template("some_template.tmpl");
     # ...
     # do some stuff and pass other params to the template
     # ...
     return $template->output();
}

[download]

this runs fine in a plain CGI environment and in mod_perl when run in single process mode (httpd -X). in a regular, multi-process mod_perl environment though, it gets a little sketchy. about 50% of the time it will die with the following error:

Error executing run mode 'some_runmode'.  Eval of code '$self->some_ru
+nmode' resulted in error: HTML::Template->new() : Unknown or unmatche
+d TMPL construct at templates/some_template.tmpl : line 1. at /usr/li
+b/perl5/site_perl/5.8.0/HTML/Template.pm line 2130.

[download]

of course, the template file itself is fine (obviously, since it runs half the time and in non-mod_perl environments). it seems to be something to do with how CGI::Application plays with mod_perl and HTML::Template.

i haven't gone through the source for CGI::Application yet. is it just not written to work safely under mod_perl? i'm pretty confident in the Foo module and the rest of the code i wrote without CGI::Application; it's been running just fine under mod_perl for a while now. it just breaks when i convert it from a collection of seperate .pl files to a single CGI::Application module.

the other (more minor) pet peeve i have with CGI::Application is that it overrides $SIG{__DIE__} so exception handling with eval { die; } doesn't work. i can work around that though. it's the problems under mod_perl that are preventing me from adding it to my toolkit.

anders pearson

Replies are listed 'Best First'.
Re: mod_perl, CGI::Application, and HTML::Template: bad combination?
by diotalevi (Canon) on Oct 31, 2002 at 09:03 UTC

    I'll just add that CGI::Application's source is short and simple - it should be easy for anyone to alter it to taste if that's really nessessary. It so happens that C::A is nicely OO so you frequently get the custom behaviour you want by overriding the appropriate methods. In my copy of C::A I don't even see $SIG{__DIE__} being tweaked directly at all - I'd just think that's from the use CGI::Carp near the top of the module. So... whatever new thing you needed it to do regarding $SIG{__DIE__} ought to be easily within your reach.

    __SIG__
use B;
printf "You are here %08x\n", unpack "L!", unpack "P4", pack
  "L!", B::svref_2object(sub{})->OUTSIDE;

    [download]
[reply]
[d/l]
[select]
Re: mod_perl, CGI::Application, and HTML::Template: bad combination?
by perrin (Chancellor) on Oct 31, 2002 at 08:09 UTC
    It definitely works under mod_perl. Jesse Erlbaum is a frequent poster on the mod_perl mailing list. You might try asking on the CGI::Application list if you don't get a good answer here.

    You should ask Jesse to consider changing that $SIG{__DIE__} business. He's a nice guy; he just might do it. (Incidentally, he lives in New York too.)

[reply]
Re: mod_perl, CGI::Application, and HTML::Template: bad combination?
by PodMaster (Abbot) on Oct 31, 2002 at 11:23 UTC
    Always mention which version of HTML::Template and CGI::Application you are using (they're important details).

    You should be using version 2.6 of both the modules (the latest at this time).

    About $SIG{__DIE__} being overriden, I see no issues with that (nor do I see him explicitly overriding $SIG{__DIE__} in the module). He uses CGI::Carp, which is just a wrapper around the Carp module, which is very stable and mature (and reccomended).

    AFAIK, CGI::Application does not do anything weird, check it out: 

    sub load_tmpl {
    my $self = shift;
    my ($tmpl_file, @extra_params) = @_;

    # add tmpl_path to path array of one is set, otherwise add a path 
+arg
    if (my $tmpl_path = $self->tmpl_path) {
            my $found = 0;
            for( my $x = 0; $x < @extra_params; $x += 2 ) {
                if ($extra_params[$x] eq 'path' and 
                    ref $extra_params[$x+1]     and
                    ref $extra_params[$x+1] eq 'ARRAY') {
                        unshift @{$extra_params[$x+1]}, $tmpl_path;
                        $found = 1;
                        last;
                }
        }
        push(@extra_params, path => [ $tmpl_path ]) unless $found;
    }

    require HTML::Template;
    my $t = HTML::Template->new_file($tmpl_file, @extra_params);

    return $t;
}

    [download]
    Now, I don't see a template method anywhere in CGI::Application, or HTML::Template, so I'd like to take this opportunity to request that you provide us with a minimal test case that demonstrates this bug, as it is most likely in your code (in the `template' method of your Foo module).

    On a HTML::Template note, if you're interested, samtregar is the dude who released HTML::Template, and I've got info on proposed patch here. He's taking it under consideration (i already have 1 patch in there), but I think it's worth while (jeffa agrees ;). Check it out and let me know what you think ;)

    Peace!

    ____________________________________________________
    ** The Third rule of perl club is a statement of fact: pod is sexy.

[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom