So you're writing a webapp using CGI::Application, you add a form to the application and set its submission method to POST and all of a sudden you can't seem to get a runmode to handle it. Instead of mixing GET and POST parameters, here's a way to convince C::A to work with POST data.
I usually use CGI::Application::Plugin::TT and CGI::Application::Plugin::AutoRunmode in my applications.
Suppose your application has two screens: statistics and administration.
In the administration screen a user can add or remove other users.
In the statistics screen a user can generate reports based on a type and some parameters.
Each of these screens corresponds to a run mode. Here's the general logic behind the runmodes:
Enter the mode and create useful objects (esp. $self = shift;)
Test to see if the form has been submitted.
If it has, process the associated information and return something useful.
If it hasn't, return the information to display.
Both methods use POST for form submission, but can be accessed by GET URL parameters by default.
When your clients visit the website http://example.com/cgi-bin/myapp?rm=stats they get sent to the statistics page and visiting http://example.com/cgi-bin/myapp?rm=admin they get sent to the administration page.
Here's the problem: When the user clicks on the "submit" button on either page, the runmode parameter (rm=stats) becomes part of the CGI environment variable QUERY_STRING (which, by definition, contains URL parameters).
Suppose your instance script (cgi-bin/myapp) looks like this:
my $app = MyApp::Admin->new();
It may not appear obvious, but without any fancy processing, passing rm?=stats will cause the value of rm to be the runmode. Read more about that here: http://search.cpan.org/~markstos/CGI-Application-4.31/lib/CGI/Application.pm .
Anyway, if you try that with a POST request, it will blow up in your face (I suggest using use CGI::Carp qw(fatalsToBrowser) to have it explode cleanly).