Mailing List Archive: Catalyst: Dev

Quick Catalyst::Plugin::SubRequest notes

Index | Next | Previous | View Threaded

pagaltzis at gmx

Mar 3, 2008, 2:53 AM

Post #1 of 9 (589 views)
Permalink

Quick Catalyst::Plugin::SubRequest notes

Hi all,

just jotting down somewhere more permanent than IRC: SubRequest
needs two things:

1. A way to return the entire ::Response object rather than just
the body.

2. An `is_subrequest` query method that, obviously enough,
returns true during a subrequest.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

ash_cpan at firemirror

Mar 3, 2008, 3:00 AM

Post #2 of 9 (572 views)
Permalink

Re: Quick Catalyst::Plugin::SubRequest notes [In reply to]

On 3 Mar 2008, at 10:53, Aristotle Pagaltzis wrote:

> Hi all,
>
> just jotting down somewhere more permanent than IRC: SubRequest
> needs two things:
>
> 1. A way to return the entire ::Response object rather than just
> the body.

Seems useful.

>
>
> 2. An `is_subrequest` query method that, obviously enough,
> returns true during a subrequest.

Why do you need this? The whole point of subreq (as I understand it)
is that it looks like a normal request.

-ash

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

pagaltzis at gmx

Mar 3, 2008, 2:01 PM

Post #3 of 9 (568 views)
Permalink

Re: Quick Catalyst::Plugin::SubRequest notes [In reply to]

* Ash Berlin <ash_cpan[at]firemirror.com> [2008-03-03 12:05]:
> On 3 Mar 2008, at 10:53, Aristotle Pagaltzis wrote:
>> 2. An `is_subrequest` query method that, obviously enough,
>> returns true during a subrequest.
>
> Why do you need this? The whole point of subreq (as I
> understand it) is that it looks like a normal request.

In my case, there are various authorisation checks in the code
that is invoked via subrequest that I want to relax. Since the
superrequest has already done its auth checks when it decides
to make the subrequest, the subrequest comes from a trusted path.

I could do this without ::SubRequest’s aid by passing a flag via
the passed-in stash. But then I’d want to sugarify this, so in
the end I’d have an `is_subreq` in MyApp.pm anyway, only it would
check a stash flag. And I’d also need need to wrap `subreq` in
MyApp.pm to always set the stash flag on the passed-in stash.

That’s not much work, admittedly, but considering how easy it is
to write `subreq` if you’re willing to peek under the hood, why
bother with the extra monkey work?

sub is_subreq {
my $self = shift;
ref $self->engine eq
'Catalyst::Plugin::SubRequest::Internal::FakeEngine';
}

But in MyApp.pm, that’s a hack. It uses knowledge of ::SubRequest
internals that aren’t advertised.

The exact same code in SubRequest.pm would be legit.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

dbix-class at trout

Mar 10, 2008, 2:32 PM

Post #4 of 9 (545 views)
Permalink

Re: Quick Catalyst::Plugin::SubRequest notes [In reply to]

On Mon, Mar 03, 2008 at 11:53:31AM +0100, Aristotle Pagaltzis wrote:
> Hi all,
>
> just jotting down somewhere more permanent than IRC: SubRequest
> needs two things:
>
> 1. A way to return the entire ::Response object rather than just
> the body.

Patches welcome.

> 2. An `is_subrequest` query method that, obviously enough,
> returns true during a subrequest.

That turns out to suck, because what happens if your subreq needs to do
some other subreq and handle that?

In any case, a subrequest should -by default- be transparent.

If you want to be able to tell, just include is_subrequest => 1 in your
stash stuff and test the stash var in your app code.

A doc patch showing how to do this would be welcome.

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

dbix-class at trout

Mar 10, 2008, 2:33 PM

Post #5 of 9 (548 views)
Permalink

Re: Re: Quick Catalyst::Plugin::SubRequest notes [In reply to]

On Mon, Mar 03, 2008 at 11:01:27PM +0100, Aristotle Pagaltzis wrote:
>
> * Ash Berlin <ash_cpan[at]firemirror.com> [2008-03-03 12:05]:
> > On 3 Mar 2008, at 10:53, Aristotle Pagaltzis wrote:
> >> 2. An `is_subrequest` query method that, obviously enough,
> >> returns true during a subrequest.
> >
> > Why do you need this? The whole point of subreq (as I
> > understand it) is that it looks like a normal request.
>
> In my case, there are various authorisation checks in the code
> that is invoked via subrequest that I want to relax. Since the
> superrequest has already done its auth checks when it decides
> to make the subrequest, the subrequest comes from a trusted path.
>
> I could do this without ::SubRequest’s aid by passing a flag via
> the passed-in stash. But then I’d want to sugarify this, so in
> the end I’d have an `is_subreq` in MyApp.pm anyway, only it would
> check a stash flag. And I’d also need need to wrap `subreq` in
> MyApp.pm to always set the stash flag on the passed-in stash.
>
> That’s not much work, admittedly, but considering how easy it is
> to write `subreq` if you’re willing to peek under the hood, why
> bother with the extra monkey work?
>
> sub is_subreq {
> my $self = shift;
> ref $self->engine eq
> 'Catalyst::Plugin::SubRequest::Internal::FakeEngine';
> }
>
> But in MyApp.pm, that’s a hack. It uses knowledge of ::SubRequest
> internals that aren’t advertised.

I don't think that would be sufficient in the general case.

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

pagaltzis at gmx

Mar 10, 2008, 7:59 PM

Post #6 of 9 (545 views)
Permalink

Re: Quick Catalyst::Plugin::SubRequest notes [In reply to]

* Matt S Trout <dbix-class[at]trout.me.uk> [2008-03-10 22:35]:
> On Mon, Mar 03, 2008 at 11:01:27PM +0100, Aristotle Pagaltzis wrote:
> > sub is_subreq {
> > my $self = shift;
> > ref $self->engine eq
> > 'Catalyst::Plugin::SubRequest::Internal::FakeEngine';
> > }
>
> I don't think that would be sufficient in the general case.

What’s missing? From looking at the code, it seems like this
should produce neither false negatives nor false positives.

* Matt S Trout <dbix-class[at]trout.me.uk> [2008-03-10 22:35]:
> On Mon, Mar 03, 2008 at 11:53:31AM +0100, Aristotle Pagaltzis wrote:
> > 1. A way to return the entire ::Response object rather than
> > just the body.
>
> Patches welcome.

OK. Any suggestions for the name of such a method? That’s the
only non-trivial part of writing one.

> > 2. An `is_subrequest` query method that, obviously enough,
> > returns true during a subrequest.
>
> That turns out to suck, because what happens if your subreq
> needs to do some other subreq and handle that?

Then you do need to twiddle the stash. But why should you *have*
to, even if you never do make nested subrequests?

> In any case, a subrequest should -by default- be transparent.

The presence of a query method wouldn’t make the subrequest any
less transparent: no controller *needs* to query the flag.

> If you want to be able to tell, just include is_subrequest => 1
> in your stash stuff and test the stash var in your app code.

That would be necessary in the general case where you want to be
able to tell nested subrequests apart, yes. I still think it’s no
skin off anyone’s back if there’s a built-in query method if you
don’t need that.

And honestly, it seems to me that if you start thinking about
nesting subrequests, it’s probably time to restructure the app.

> A doc patch showing how to do this would be welcome.

Yes, good idea.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

pagaltzis at gmx

Mar 10, 2008, 8:26 PM

Post #7 of 9 (540 views)
Permalink

Re: Quick Catalyst::Plugin::SubRequest notes [In reply to]

Oh yeah,

[.a user question, so I’m taking this over to the other list]

* Aristotle Pagaltzis <pagaltzis[at]gmx.de> [2008-03-11 03:59]:
> And honestly, it seems to me that if you start thinking about
> nesting subrequests, it’s probably time to restructure the app.

the reason I used ::SubRequest in my case is because I cannot see
any easy way to forward to an entire chain. It goes like this:

I have a chain that dispatches a URL `/app/trial/23` like so:

/internal (checks if user is logged in)
/trial/base (stash a bunch of things common to all trials)
/trial/item (stash the data for the trial #23, or 404 if absent)
/trial/view (dummy)

(The last step is necessary because `item` is CaptureArgs(1) so
I can have URLs like `/app/trial/23/edit`.)

Anyway, so, I also have URLs like `/clinicXY/trial/23`, which I
want to serve basically in the same way as `/app/trial/23`,
except with a different wrapper template and slightly for
different permission checks as that is a publically visible page
whereas `/app/trial/23` is only accessible to logged in users.

Unfortunately for me, `$c->forward` doesn’t work that way – if I
forward to an action, it forwards to *that one* action,
disregarding the rest of the chain ahead of it. I’m not
complaining about that as I see the utility of it.

Now I really like the way chains let me populate the stash in
little steps; but that means running `/trial/view` makes no sense
at all in my app without running `/trial/base` and `/trial/item`
beforehand. So when I forward to `/trial/view`, what I really
need is to include to the entire chain that leads up to it. I
could do write that out manually, but then I’d be hardcoding a
repetition of the chain everywhere I need to forward to it.

So I ended up using ::SubRequest because that launches a full
subordinate dispatch cycle which will chain properly and DRYly.

Is that a recommendable solution, or am I bringing out the
combine harvester to tidy up a flower pot?

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

pagaltzis at gmx

Mar 17, 2008, 4:48 AM

Post #8 of 9 (513 views)
Permalink

Re: Quick Catalyst::Plugin::SubRequest notes [In reply to]

* Pedro Melo <melo[at]simplicidade.org> [2008-03-17 11:20]:
> I needed that once, and after advise from mst, I used a base
> controller. Basically, I implemented the entire chain in a base
> controller, and then I create a normal controller, that defines
> the base URL (in your case /clinicXY). So each /clinicXY would
> have a different controller, with a common base class
> implementing your stuff.
>
> This worked very well. Of course, I needed just 8 of those
> clinicXY bases. If you have some requirement like NNNN such
> bases, you might need another path.

Yes, he told me the same on IRC and I was actually planning to go
that route. Except that the set of `clinicXY`, `clinicYZ` etc
strings come from the database and can change at runtime. So I’d
need to create and destroy controller classes on the fly… uhm,
not good.

Also, there are two bits of logic, one shared by all staff-only
pages and one shared by all public pages. So dispatching them
through two separate chains and using the base in each chain to
run the respective logic seems like a good way to address that.

Finally, I like the fact that public URIs are dispatched through
a separate chain from staff-only ones, because it frees me from
having to be very careful with my auth checks. Only the things I
put into the Portal controller can ever be reached by the public
anyway.

The only thing I don’t like about this arrangment is that some
public pages share both their template and their database queries
with the corresponding staff-only pages. (They differ in wrapper
template only.) Forwarding to the staff-only chain after setting
a flag to relax auth checks seems the most concise way to take
care of those pages – except that it doesn’t seem possible to
forward to an entire chain, only to a single action.

So I have to issue a subrequest.

Or do I?

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

rick at bort

Mar 21, 2008, 8:20 PM

Post #9 of 9 (487 views)
Permalink

Re: Re: Quick Catalyst::Plugin::SubRequest notes [In reply to]

On Mar 17 2008, Aristotle Pagaltzis wrote:
> Yes, he told me the same on IRC and I was actually planning to go
> that route. Except that the set of `clinicXY`, `clinicYZ` etc
> strings come from the database and can change at runtime. So I’d
> need to create and destroy controller classes on the fly… uhm,
> not good.
>
> Also, there are two bits of logic, one shared by all staff-only
> pages and one shared by all public pages. So dispatching them
> through two separate chains and using the base in each chain to
> run the respective logic seems like a good way to address that.

Bear in mind I'm pretty new to Catalyst but could you not just create a
chain like

/*/trial/23

and dispatch within the base to your different logic? Something like

sub base : Chained('/') PathPart('') CaptureArgs(1) {
my ($self, $c, $base) = @_;
$self->dispatch($base, $c);
}

sub view : Chained('base') PathPart('trial') Args(1) { ... }

> Finally, I like the fact that public URIs are dispatched through
> a separate chain from staff-only ones, because it frees me from
> having to be very careful with my auth checks. Only the things I
> put into the Portal controller can ever be reached by the public
> anyway.

This sounds like separation into different virtual hosts might be
easier.

--
Rick Delaney
rick[at]bort.ca

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com