On Wed, Jun 06, 2007 at 05:22:43PM -0700, mla wrote:
> Assuming I'm not using threads, how would I hurt myself by
> subclassing Catalyst and supplying a MyApp->context that returns
> the current catalyst context?
If you think magic globals are a good thing, I have a PHP interpreter to
sell you.
-
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 t
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 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 ACCEPT_CONTEXT prototype object thing?
Not without limiting ours
On Wed, Jun 06, 2007 at 12:29:12PM -0700, mla wrote:
> 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
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 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 destructio
On Jun 5, 2007, at 12:33 PM, Matt S Trout wrote:
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 mig
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 alread
> 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, s/controllers
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
$c->twiddle_with_session()
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 he
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: http://lists
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 easi
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 exp
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 o
On Tue, 2007-06-05 at 22:30 +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 explai
ot; plugin would that improve the NEXT 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
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
On Mon, Jun 04, 2007 at 08:04:01PM -0700, [EMAIL PROTECTED] 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 single method call on $c
> > (there's
> >
07 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 to return
>> > the debug flag from $c->config->{
On Mon, Jun 04, 2007 at 05:47:32PM -0400, John Goulah wrote:
> Did you have to do anything in lib/MyApp.pm to get this to work? It seems
> I would want to add this plugin, but Catalyst cant find it. I'm probably
> doing something very obviously wrong, but I havent tried to write my own
> plugins
-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 over
On Mon, Jun 04, 2007 at 10:32:07AM -0400, 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 s
On 6/4/07, Matthew Pitts <[EMAIL PROTECTED]> wrote:
I wrote a cheap little plugin for my app to override $c->debug to return
the debug flag from $c->config->{debug}. As such:
package MyApp::Plugin::DebugMode;
sub debug {
my $c = shift;
return $c->config->{debug} || 0;
}
1;
Then I ju
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 ch
Monday, June 04, 2007 7:51 AM
To: 'The elegant MVC web framework'
Subject: RE: [Catalyst] debug mode
I thought a nice way would be to be able to specify it in the
config file; then your _local.yml file could add it for the dev
environment. Yet to pro
I wrote a cheap little plugin for my app to override $c->debug to return
the debug flag from $c->config->{debug}. As such:
package MyApp::Plugin::DebugMode;
sub debug {
my $c = shift;
return $c->config->{debug} || 0;
}
1;
Then I just add a "debug: 1" line to my DEV/QA/UAT configs and m
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
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 use the following in sandbox httpd.conf's:
BEGIN { $ENV{MYAPP_DEBUG} = 1; }
use MyApp;
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 the fl
I thought a nice way would be to be able to specify it in the config file;
then your _local.yml file could add it for the dev environment. Yet to
produce a patch for that though it should be pretty straight forwards.
Mark
_
From: John Goulah [mailto:[EMAIL PROTECTED]
Sent: 04 June 2007
32 matches
Mail list logo
