[Catalyst] Cascading action dispatching

Matt S Trout dbix-class at trout.me.uk
Tue Oct 23 20:35:13 GMT 2007


On Tue, Oct 23, 2007 at 07:40:36AM -0700, John Napiorkowski wrote:
> 
> --- Matt S Trout <dbix-class at trout.me.uk> wrote:
> 
> > On Sun, Oct 21, 2007 at 10:20:20AM -0400, Matthew
> > Pitts wrote:
> > > On Fri, 2007-10-19 at 17:16 -0400, Matthew Pitts
> > wrote:
> > > > 
> > > > I'm trying to figure out a way to have my Cat
> > app dispatch in a way
> > > > that
> > > > would allow multiple actions in the same
> > namespace and have them
> > > > called
> > > > in succession until one of them actually handles
> > the request.
> > > > 
> > > > I have a client that really likes base-level
> > URLs, like
> > > > "/shoppingmallxyz", and wants to use them for
> > landing pages that are
> > > > functionally different. In some of these cases
> > the base-level URL
> > > > paths
> > > > are really just monikers for things that are
> > retrieved from the DB and
> > > > if it exists, then a page is rendered.
> > > 
> > > I guess another, maybe more elegant, way to
> > accomplish this same effect
> > > would be to override register_actions in the
> > Controllers where I want to
> > > do this and have a call to a
> > register_dynamic_actions method like so:
> > > 
> > > package MyApp::Controller::Center;
> > > 
> > > sub register_actions {
> > >     my $self = shift;
> > >     my ( $c ) = @_;
> > > 
> > >     $self->register_dynamic_actions($c);
> > > 
> > >     return $self->SUPER::register_actions(@_);   
> > # or NEXT?
> > > }
> > > 
> > > sub register_dynamic_actions {
> > >     my $self = shift;
> > >     my ( $c ) = @_;
> > > 
> > >     my $centers = $c->model('Center')->all;
> > > 
> > >     while ( my $center = $centers->next ) {
> > >         my $action = $self->create_action(...);
> > >         $c->dispatcher->register($c, $action);
> > >     }
> > > }
> > > 
> > > 1;
> > > 
> > > An obvious side-effect (AFAIK) of doing it this
> > way is that the app has
> > > to be restarted for new dynamic actions to take
> > affect. The benefit,
> > > however, is that the root-level pseudo-actions I
> > was trying to achieve
> > > with on-the-fly DB lookups are now first class
> > actions and would not
> > > require a DB call on each request.
> > > 
> > > I may be crazy... anybody got any thoughts on
> > this?
> > 
> > Yes, you're crazy.
> > 
> > OTOH you appear to be the same same sort of crazy I
> > was when I wrote
> > register_actions and intentionally factored the
> > process in such a way
> > that it was overridable, so don't let that stop you
> > implementing this.
> > 
> > The only better solution I can think of is to handle
> > whether you accept the
> > action via an action class, but we need to add a
> > $action->match_captures for
> > chain mid-points to make that elegant, currently you
> > only get a match on the
> > end point which would be a bit messy to implement.
> > 
> > I plan to add such a method for 5.80
> 
> Matt,
> 
> I actually started playing with this a few months ago
> (wrote some tests for the expected behavior, etc) but
> had a little trouble getting it to work correctly. 
> Did you actually start on this?  Because if you have a
> plan I would be happen to be the implementation
> monkey.  --John

You'd need to build up the ActionChain object so when you call match_captures
on $midpoint_action it sees the rest of the actions already in the chain.

If you fancy throwing up a 5.80 branch and putting in your tests I can have
a dig around, I really doing think the implementation will be much work.

-- 
      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/



More information about the Catalyst mailing list