Rhesa Rozendaal wrote:
Richard Jones wrote:
> Mark Stosberg wrote:
>> On Fri, 07 Nov 2008 13:44:40 +0000 Richard Jones
>> <[EMAIL PROTECTED]> 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
##### CGI::Application community mailing list ################
## ##
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
################################################################
