Re: [Catalyst] RunAfterRequest/delayed Catalyst view
On Fri, Apr 30, 2010 at 3:59 PM, Steve Kleiman wrote: > That's definitely my fallback if necessary. I really like using the > Catalyst-centric option because it's easier for my brain to > compartmentalize. It keeps the email dispatching process consistent with the > rest of the Email::Template paradigm used throughout my app. > > Also it's not just for email I'm using RunAfterRequest...it's a bunch of > slow database processing that leads up to the generation of the email. So I > was hoping to drop the whole bit into RunAfterRequest instead of having a > cron job deal with it. Keeps all my stuff in one place and for a Catalyst > newbie that's a nice thing (if it works). > Ya, it's a fine line. I tend to think Catalyst's job is to handle a request and return the response as soon as possible and then move on to serve another request. But, if you have processes to spare then why not use them? Might need to think about other things like how a long running process might effect the need to restart the sever, etc. Job queues are nice. -- Bill Moseley mose...@hank.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Returning error codes to the user.
I have a CRUD interface to an application. This is used for both the Web
and directly as an API.
The model uses DBIC which, as you know, allows chaining resultsets, which I
use to add additional constraints to the result set.
So, a request for, say, /user/1234 might result in:
$c->model( 'App::User' )->search(
{
'me.id' => $requested_user_id,
'me.active => 1,
'me.date_expires' => [
{ '>' => \'now()' }, # past expired
{ '=' => undef }, # or never expires
],
'account.active'=> 1,
'account.balance' => { '>' => 0 },
'account.locked'=> 0,
'account.date_expires' => [
{ '>' => \'now()' }, # past expired
{ '=' => undef }, # or never expires
],
},
{
join => 'account',
},
);
[That's not a great example because we assume that "user" and "account"
might get checked when first logging in. Ignore that. Just assume a query
that does a lot of joins to test if a given object can be accessed.]
The request either succeeds (200) or fails (404).
The VAST majority of the time the ID provided will return a row because a
valid ID was provided by the application itself in the first place.
But, for a tiny, tiny percent a request might fail. Then the question is
*why* did it fail? What WHERE condition or join failed?
Just like our favorite topic premature optimization, I don't think it would
be wise to write the above in multiple stages (and multiple requests to the
database) just to check each step for something that almost never fails.
On the other hand, it's not unreasonable for an API request to return a
reason why something failed. Sure would make tech support's life easier.
So, what would you recommend? Have a separate /user/$id/debug method that
does a separate step-by-step of the business logic? Scrap all that really
handy chaining of resultsets that works so well with Catalyst's chained
actions?
--
Bill Moseley
mose...@hank.org
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RunAfterRequest/delayed Catalyst view
That's definitely my fallback if necessary. I really like using the Catalyst-centric option because it's easier for my brain to compartmentalize. It keeps the email dispatching process consistent with the rest of the Email::Template paradigm used throughout my app. Also it's not just for email I'm using RunAfterRequest...it's a bunch of slow database processing that leads up to the generation of the email. So I was hoping to drop the whole bit into RunAfterRequest instead of having a cron job deal with it. Keeps all my stuff in one place and for a Catalyst newbie that's a nice thing (if it works). Steve Kleiman st...@prodhub.com On Apr 30, 2010, at 3:46 PM, Bill Moseley wrote: > > > On Fri, Apr 30, 2010 at 2:38 PM, Steve Kleiman wrote: > Here goes...hopefully a simple test case for the RunAfterRequest oddness. > > > This is really not the response you were hoping for, but have you considered > not using RunAfterRequest? I either send email directly during the request > to the local sendmail or I write it to a store and another (non-web) process > on a separate machine (or machines) manage delivering the mail. > > -- > Bill Moseley > mose...@hank.org > ___ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RunAfterRequest/delayed Catalyst view
On Fri, Apr 30, 2010 at 2:38 PM, Steve Kleiman wrote: > Here goes...hopefully a simple test case for the RunAfterRequest oddness. > > This is really not the response you were hoping for, but have you considered not using RunAfterRequest? I either send email directly during the request to the local sendmail or I write it to a store and another (non-web) process on a separate machine (or machines) manage delivering the mail. -- Bill Moseley mose...@hank.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RunAfterRequest/delayed Catalyst view
Here goes...hopefully a simple test case for the RunAfterRequest oddness.
The code below works as expected...an email is dispatched.
==
sub tester :Local {
my ( $self, $c ) = @_;
$c->stash(
email =>{
to =>
'st...@prodhub.com',
from=>
'bocks...@mac.com',
subject =>
'RunAfterRequest Test',
templates
=> [
{
template=> 'test.tt2',
content_type=> 'text/plain',
view=> 'TT',
},
],
},
);
$c->forward( $c->view('Email::Template') );
$c->response->body('foo bar');
}
==
The code below with the forward INSIDE 'run_after_request' subroutine throws
the error:
> [error] Caught exception in engine "Modification of non-creatable array value
> attempted, subscript -1 at
> /usr/local/lib/perl5/site_perl/5.10.1/Catalyst/Dispatcher.pm line 278."
Doesn't matter whether the stash call is inside or outside the subroutine.
==
sub tester :Local {
my ( $self, $c ) = @_;
$c->stash(
email =>{
to =>
'st...@prodhub.com',
from=>
'bocks...@mac.com',
subject =>
'RunAfterRequest Test',
templates
=> [
{
template=> 'test.tt2',
content_type=> 'text/plain',
view=> 'TT',
},
],
},
);
$c->run_after_request( sub {
$c->forward( $c->view('Email::Template') );
});
$c->response->body('foo bar');
}
==
The Catalyst::Dispatcher code where the error occurs is the $c->stack line
below:
==
sub _action_rel2abs {
my ( $self, $c, $path ) = @_;
unless ( $path =~ m#^/# ) {
my $namespace = $c->stack->[-1]->namespace;
$path = "$namespace/$path";
}
$path =~ s#^/##;
return $path;
}
==
[END]
On Apr 29, 2010, at 11:18 PM, Devin Austin wrote:
>
>
> On Fri, Apr 30, 2010 at 12:09 AM, Tomas Doran wrote:
>
> On 30 Apr 2010, at 07:00, Steve Kleiman wrote:
> Thanks in advance for any insights.
>
> No id
