[Catalyst] patch to C::P::SubRequest / RFC

luke saunders luke.saunders at gmail.com
Fri Jun 16 18:07:09 CEST 2006


I've noticed that if, using C::P::SubRequest, action_a subreqs to
action_b and action_b does $c->res->status(400) then action_a will
also return a 400 unless overridden. This is also the case for any
other changes to $c->res that the subreq'd action might make.

This is because C::P::SubRequest doesn't give the subreq'd action its
own Response object. There was some discussion on #catalyst where it
was pretty much decided that this was wrong.

Attached is a patch which changes SubRequest.pm so that it passes the
subreq'd action a shiny new Response object to prevent it stamping all
over the original. It's feasible that the calling action may actually
be interested in the subreq'd action's Response object (for status
code checking etc) and for this reason if subreq is called in list
context the subreq'd action's Response object is returned as the
second return value: my ($body, $res) = $c->subreq(...)

Ideally, the subreq'd action should probably get a whole $c of its
own, but this would require much work. So I propose that this will do
for now .

There may be a problem with backwards compatibility if this patch is
actually applied, so maybe this new behaviour should only occur if
some flag is set or if subreq_local (or whatever) is called instead.

Any thoughts?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: subreq.patch
Type: application/octet-stream
Size: 2863 bytes
Desc: not available
Url : http://lists.rawmode.org/pipermail/catalyst/attachments/20060616/281a4904/attachment.obj 


More information about the Catalyst mailing list