On Tue, Jun 05, 2007 at 01:42:42PM -0700, Michael Reece wrote:
sub _ACTION : Pricvate {
my ($self, $c) = @_;
$self-_context($c);
$self-SUPER::_ACTION($c);
}
That's not only in the wrong place to work for begin/end/auto it
screws up
the destruction process and is
Matt S Trout wrote:
On Tue, Jun 05, 2007 at 01:42:42PM -0700, Michael Reece wrote:
sub _ACTION : Pricvate {
my ($self, $c) = @_;
$self-_context($c);
$self-SUPER::_ACTION($c);
}
That's not only in the wrong place to work for begin/end/auto it
screws up
the destruction process and
On Wed, Jun 06, 2007 at 02:18:33PM -0700, mla wrote:
Matt S Trout wrote:
On Wed, Jun 06, 2007 at 12:29:12PM -0700, mla wrote:
Is it not possible to offer the current Catalyst instance through
a class method? Something analogous to Apache-request, rather than
having to do the whole
Matt S Trout wrote:
On Wed, Jun 06, 2007 at 02:18:33PM -0700, mla wrote:
Matt S Trout wrote:
On Wed, Jun 06, 2007 at 12:29:12PM -0700, mla wrote:
Is it not possible to offer the current Catalyst instance through
a class method? Something analogous to Apache-request, rather than
having to do
Good evening,
On 5/6/07 at 1:17 AM +0100, Matt S Trout
[EMAIL PROTECTED] wrote:
in lib/MyApp.pm:
use Catalyst qw/
+MyApp::Plugin::DebugMode
...
/;
The + is important.
Would you mind explaining that a bit further? Or pointing to
documentation? When is it appropriate to use the + and
performance?
Thanks,
Matt
-Original Message-
From: Matthew Pitts [mailto:[EMAIL PROTECTED]
Sent: Monday, June 04, 2007 8:23 AM
To: The elegant MVC web framework
Subject: RE: [Catalyst] debug mode
I wrote a cheap little plugin for my app to override
$c-debug
On Tue, Jun 05, 2007 at 08:40:52AM -0400, Matthew Pitts wrote:
On Tue, 2007-06-05 at 01:18 +0100, Matt S Trout wrote:
On Mon, Jun 04, 2007 at 12:55:38PM -0700, Dylan Vanderhoof wrote:
Oh, missed this email. Yours looks better than mine. =)
Except for being a performance hit on every
On Tue, Jun 05, 2007 at 10:30:49PM +1000, Charlie Garrison wrote:
Good evening,
On 5/6/07 at 1:17 AM +0100, Matt S Trout
[EMAIL PROTECTED] wrote:
in lib/MyApp.pm:
use Catalyst qw/
+MyApp::Plugin::DebugMode
...
/;
The + is important.
Would you mind explaining that a bit
FWIW
I just turn debug off, and do
export MYAPP_DEBUG=1; script/myapp_server.pl -r;
as I am developing. As that line is always there in the command buffer
it's no hassle. If I want I can have
BEGIN {
$ENV{MYAPP_DEBUG} = 1;
}
in test scripts.
Basically i find just using one mechanism is
Daniel McBrearty wrote:
FWIW
I just turn debug off, and do
export MYAPP_DEBUG=1; script/myapp_server.pl -r;
the -d option is so much easier to type :)
script/myapp_server.pl -d -r
-Brian
___
List: Catalyst@lists.rawmode.org
Listinfo:
Good morning,
On 5/6/07 at 8:52 AM -0400, Matthew Pitts [EMAIL PROTECTED] wrote:
So...
use Catalyst qw/
+MyApp::Plugin::DebugMode
/;
will load the MyApp::Plugin::DebugMode package. Without the '+' it would
try to find Catalyst::Plugin::MyApp::Plugin::DebugMode.
Hope this helps.
I
if the catalyst base controller class provided an easy way to access $c
from a utility method (vs an action method, which receives $c
'automatically'), then i think plugins might be a little less popular.
some of my bits have ended up as controllers because i'd rather
if the catalyst base controller class provided an easy way to access $c
from a utility method (vs an action method, which receives $c
'automatically'), then i think plugins might be a little less popular.
some of my bits have ended up as controllers because i'd rather
oops,
On Tue, Jun 05, 2007 at 08:04:03AM -0700, [EMAIL PROTECTED] wrote:
if the catalyst base controller class provided an easy way to access $c
from a utility method (vs an action method, which receives $c
'automatically'), then i think plugins might be a little less popular.
Well, you can already
What is the best way to deal with the -Debug flag between a production and
development environment? Obviously its not desirable to go into the file
and remove the flag every time the code goes to prod. I see you can start
the stanalone server with -d to force debug. I think I remember about
2007 15:32
To: The elegant MVC web framework
Subject: [Catalyst] debug mode
What is the best way to deal with the -Debug flag between a production and
development environment? Obviously its not desirable to go into the file
and remove the flag every time the code goes to prod. I see you can start
i use the following in sandbox httpd.conf's:
Perl
BEGIN { $ENV{MYAPP_DEBUG} = 1; }
use MyApp;
/Perl
and s/1/0/ for prod.
What is the best way to deal with the -Debug flag between a production and
development environment? Obviously its not desirable to go into the file
and remove
John Goulah wrote:
What is the best way to deal with the -Debug flag between a
production and development environment? Obviously its not desirable
to go into the file and remove the flag every time the code goes to
prod. I see you can start the stanalone server with -d to force
debug. I
On Mon, 4 Jun 2007, John Goulah wrote:
What is the best way to deal with the -Debug flag between a production and
development environment? Obviously its not desirable to go into the file
and remove the flag every time the code goes to prod. I see you can start
the stanalone server with -d to
for that though it should be pretty straight
forwards.
Mark
__
From: John Goulah [mailto:[EMAIL PROTECTED]
Sent: 04 June 2007 15:32
To: The elegant MVC web framework
Subject: [Catalyst] debug mode
What
Oh, missed this email. Yours looks better than mine. =)
-D
-Original Message-
From: Matthew Pitts [mailto:[EMAIL PROTECTED]
Sent: Monday, June 04, 2007 8:23 AM
To: The elegant MVC web framework
Subject: RE: [Catalyst] debug mode
I wrote a cheap little plugin for my app
21 matches
Mail list logo
