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

I just got bit by a change in the latest version of CGI::Application that appears to be undocumented. I'm wondering if I'm doing things incorrectly or if I should send the author a bug report.

The problem, at first glance, is that my application will only return the default run mode. I am setting mode_param() in cgiapp_init to something other than rm. Looking back in the docs, I see "mode_param is generally called in the setup() method," which leads me to believe my calling it in cgiapp_init should be valid. Otherwise, I would have to make the same mode_param call in setup of all the subclasses of my custom base class.

The problem is that, prior to 4.02, the CGI::Application new() method looked like so:

sub new {
    # ... miscellany

    # Create our object!
    my $self = {};
    bless($self, $class);

    ### SET UP DEFAULT VALUES ###
    #
    # We set them up here and not in the setup() because a subclass
    # which implements setup() still needs default values!

    $self->header_type('header');
    $self->mode_param('rm');
    $self->start_mode('start');

    # ... remainder of constructor,
    # including init and setup calls
}

[download]
Now those defaults have been moved until just before setup(), the final call, meaning they overwrite anything set in the init phase: 
sub new {
    # ... miscellany

    # Call cgiapp_init() method, which may be implemented in the sub-c
+lass.
    # Pass all constructor args forward.  This will allow flexible usa
+ge
    # down the line.
    $self->call_hook('init', @args);

    ### SET UP DEFAULT VALUES ###
    #
    # We set them up here and not in the setup() because a subclass
    # which implements setup() still needs default values!

    $self->header_type('header');
    $self->mode_param('rm');
    $self->start_mode('start') unless defined $self->start_mode;

    # Call setup() method, which should be implemented in the sub-clas
+s!
    $self->setup();

    return $self;
}

[download]

I suppose the purpose of this post is twofold. One, don't get caught like this if you upgrade CGI::Application. :-) Two, am I doing the wrong thing by calling mode_param from a parent class cgiapp_init?

Replies are listed 'Best First'.
Re: Changes in Latest Version of CGI::Application (4.02)
by markjugg (Curate) on Aug 04, 2005 at 20:18 UTC
    I'm the guilty party, and I just got bit by the change, too. Michael Graham mailed me privately to provide additional insight. We'll take care of it ASAP.

    It seemed like a minor change... and the whole test suite passed, but there apparently was no test for this changed behavior.

    Mark Stosberg

[reply]
      ...we ARE the test! :-) ---v

      ...All the world looks like -well- all the world, when your hammer is Perl.
      ---v
[reply]
      hmm, and I should be posing as the hoplite for this module but have not doing my job for a while. It seem so much time that the module was even removed from the Phalanx list. I should check the coverage of the module again and improve it if there big holes in the test suit.
[reply]
        Curiously, Devel::Cover wouldn't have caught this, because all the code was executed already by the test suite. It's only when you override particular methods that the bug is exposed.

        So it would be quite possible to write a test for it, although difficult to detect that the case wasn't covered by a test.

        Mark Stosberg

[reply]
Re: Changes in Latest Version of CGI::Application (4.02)
by cees (Curate) on Aug 04, 2005 at 19:22 UTC

    Although it is standard practise to set the mode_param in your setup method, what you are doing is not wrong. So I would say that this is a bug in CGI::Application, and you should send it in (either through rt.cpan.org or send a quick message to the list at cgiapp@lists.erlbaum.net).

    Update: An updated version (4.03) of CGI::Application which solves this problem is on its way to CPAN.

[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom