[cgiapp] Re: CAP::AutoRunmode not working with mod_perl again ??

[Richard Jones]

Rhesa Rozendaal wrote:
>  Richard Jones wrote:
> > Mark Stosberg wrote:
> >> On Fri, 07 Nov 2008 13:44:40 +0000 Richard Jones
> >> <ra.jones at dpw.clara.co.uk> wrote:
> >>
> >>> I know this was supposed to be fixed in v0.14 but it seems to
> >>> be happening again. In a trivial setup:
> >> That sounds frustrating Richard. I haven't gone back to use
> >> AutoRunmode after getting bitten the first time around with the
> >> mod_perl issue. Have you tried the RunmodeDeclare plugin as an
> >> alternative?
> >
> > Hi Mark,
> >
> > Yes I have - and it does now seem to work OK under all 3 envs
> > (mod_perl, HTTP::Simple::Server/CA::Server & mod_cgi), but I'm
> > still a little wary of it as it seems to use deeper magic than
> > AutoRunmode, and I'm not sure all the issues that were discussed
> > earlier [RFC: declarative run modes (inspired by
> > Method::Signatures)] have been addressed. Is RunmodeDeclare 'safe'
> > to use in production in combination with many other plugins (eg
> > CAP::Authentication, CAP::Authorization, etc) yet?
>
>  As far as I know, we fixed all the issues mentioned in that thread.
>  I've been using RunmodeDeclare in production for a couple of weeks
>  now, and it works fine. Since we have quite a few customers running
>  their (online) business on our software, I tend to be careful with
>  what I put into production. And I'm quite comfortable running it.
>
OK, that's good to hear. So far on a small sub-set of my app it's 
working fine, providing I *don't* mix run_mode declaration methods - see 
below.

>  We use at least the following plugins in our apps:
>
>  CA::Dispatch
 > CAP::AutoRunmode
 > CAP::Session
 > CAP::Authentication
>  CAP::Authorization
>
>
I'm using a few more, and as far as I can tell so far they are all 
working OK with RunmodeDeclare:

CGI::Application::Plugin::Forward
CGI::Application::Plugin::Redirect
CGI::Application::Plugin::Session
CGI::Application::Plugin::ValidateRM
CGI::Application::Plugin::ConfigAuto
CGI::Application::Plugin::DBH
CGI::Application::Plugin::TT
CGI::Application::Plugin::Stash
CGI::Application::Plugin::Authentication
CGI::Application::Plugin::Authorization
CGI::Application::Plugin::LogDispatch

> > The choice actually is a) fix AutoRunmode - preferable as my app.
> > is already working with it (except under mod_perl); b) switch to
> > RunmodeDeclare, where I will have a lot of code to convert and is
> > pretty much a one-way ticket; and c) revert to the traditional
> > method of declaring $self->run_modes & $self->start_mode in
> > setup(), which can probably be considered the safer option.
>
>
>  We use all three methods of registering run modes in our application:
>  we started out with the traditional way of calling "run_modes",
>  "start_mode" and "error_mode" in "setup". Later on, we adopted
>  CAP::AutoRunmode for newer code, and recently I've been moving us
>  over to RunmodeDeclare in new cgiapp modules, or when I have a need
>  to refactor existing code. All three methods run happily together. In
>  fact, you could use all three in the same module, but I wouldn't
>  recommend that from a maintainability viewpoint.
>


Well, I tried it with RunmodeDeclare in a sub-class that inherits from a 
super-class that uses AutoRunmode methods, and it bombed trying to load 
the super-class startmode template (menu.tt) in the sub-class startmode 
template path - ie should have loaded /admin/user/function/default.tt, 
but tried to load /admin/user/function/menu.tt, which is the superclass 
default template in /admin/menu.tt. But as I mentioned above, providing 
I use RunmodeDeclare throughout, it seems fine. It's probably also OK to 
mix-n-match, within an app, providing it's not in a subclass/superclass 
pair.
--
Richard Jones