[Catalyst] Re: Quick Catalyst::Plugin::SubRequest notes

[Pedro Melo]

Hi,

On Mar 11, 2008, at 3:26 AM, Aristotle Pagaltzis wrote:
> 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?


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.

Best regards,
-- 
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo at simplicidade.org
Use XMPP!