On Thu, Feb 26, 2009 at 8:23 AM, Ovid <publiustemp-catal...@yahoo.com>wrote:
> _______________________________
> From: J. Shirley <jshir...@gmail.com>
>
> > If you structure your base class properly, and then in each class you
> configure where to chain from:
> >
> > __PACKAGE__->config(
> > actions => { 'setup' => { Chained => '/some/other/chain', PathPart
> => 'api' } }
> > );
> >
> > You can override any of the methods along the way. I tend to use this
> structure in my base class:
> >
> > sub setup : Chained('.') PathPart('something') CaptureArgs(0) { }
> >
> > sub root : Chained('setup') PathPart('') Args(0) { }
> >
> > sub object_setup : Chained('setup') PathPart('id') CaptureArgs(1) { }
> >
> > sub object : Chained('object_setup') PathPart('') Args(0) { }
> >
> > This way, you could add a: sub doc : Chained('setup') PathPart('doc')
> Args(0) { } method and you would always have it.
>
> I'm not entirely sure I follow all of that. Right now, our
> PIPs::C::API::V1::Episode might handle:
>
> /api/v1/episode/
> /api/v1/episode/pid.b0070xmk/
> /api/v1/episode/pid.b0070xmk/children/
> /api/v1/episode/pid.b0070xmk/children/versions
>
Sure, this is easy with chained.
At a Root level:
sub api : Chained('/') CaptureArgs(0) { }
sub version_1 : Chained('api') PathPart('v1') CaptureArgs(0) { }
package Controller::Version1::Episode;
use parent 'MyApp::ControllerBase::REST';
__PACKAGE__->config(
class => 'MyAppDB::Episode',
...
);
sub children : Chained('object_setup') PathPart('') CaptureArgs(0) { }
1;
package Controller::Version1::Episode::Children;
use parent 'MyApp::ControllerBase::REST';
__PACKAGE__->config( ... );
# Override setup to look at the current episode
sub setup : Chained('/version1/episode/object_setup') PathPart('children')
CaptureArgs(0) {
my ( $self, $c ) = @_;
$c->stash->{ children } = $c->stash->{episode}->children;
}
# Only exists on children, as an example (not in the base class)
sub versions : Chained('setup') Args(0) ActionClass('REST') { }
1;
> And each of those needs a doc:
>
> /api/v1/episode/doc/
> /api/v1/episode/pid.b0070xmk/doc/
> /api/v1/episode/pid.b0070xmk/children/doc/
> /api/v1/episode/pid.b0070xmk/children/versions/doc/
>
> It doesn't really look like your solution handles variable length URL
> paths, will it?
>
By "variable length" I'm not sure what you mean. I think of URIs as an
identifier to a resource (being REST, that's the only way to think). This
means you have two types of 'things' between slashes; the first type is a
path part and the second is an argument.
If you cannot programmatically calculate your URI, I doubt they can
accurately represent a stateless entity. It looks to me like you have a
well defined URI format though, and if you had a common base class that all
controllers inherited from and used that to generate your chains
> So Catalyst doesn't offer any simple way of saying "globally match
> {^(.*)/doc$} against a desired controller? (the controller for $1 in this
> case)
>
I don't know, matching via regular expression is not something I would do.
I'm simply addressing the "Yes, you can use chained" perspective.
>
> > I have an example app on github that demonstrates this idea more:
> http://github.com/jshirley/catalystx-example-chained/tree/master
> >
> > I'm currently using this same mechanism in a similar way, except instead
> of a 'doc' it is a 'search' method ...
>
> I can't find that "search" method anywhere in that code (forced to examine
> it through the Web interface due to our firewalls).
>
No, the example on github is just demonstrating base classes. The search
method I spoke of is just in the base class and handles setting the result
class to HashRefInflator, and providing pagination and sorting based on
incoming parameters. On any REST controllers that don't support search, I
simply do: "sub search { }" and they don't have that action.
-J
_______________________________________________
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/
