Re: [Catalyst] PathPart help
On Mon, Nov 19, 2007 at 09:41:06AM +0100, Dami Laurent (PJ) wrote:
> >-Message d'origine-
> >De : Matt S Trout [mailto:[EMAIL PROTECTED]
> >Envoyé : samedi, 17. novembre 2007 12:40
>
> [ snip ]
>
> >
> >What I'd do instead is -
> >
> >package MyApp::ControllerBase::HasObject;
> >
> >sub has_object :PathPart('') :CaptureArgs(0)
> >sub edit :Chained('has_user') :PathPart('edit') :Args(0)
> >
> >package MyApp::ControllerBase::ChainBase;
> >
> >__PACKAGE__->mk_accessors(qw(object_chains));
> >
> >__PACKAGE__->config(object_chains => []);
> >
> >sub COMPONENT {
> > my $new = shift->NEXT::COMPONENT(@_);
> > foreach my $chain (@{$new->object_chains}) { # commented
> >using example 'id'
> >my $action = $self->action_for($chain); # Catalyst::Action
> >for /foo/id
> >my $pkg = ref($new).'::'.ucfirst($chain); # 'id' ->
> >Controller::Foo::Id
> >{
> > no strict 'refs';
> > @{"${pkg}::ISA"} = 'MyApp::ControllerBase::HasObject'; #
> >inject base class
> >}
> ># Set :Chained('id') on Controller::Foo::Id->has_user
> >$pkg->config(actions => { has_object => { Chained =>
> >$action->reverse } });
> > }
> > return $new;
> >}
> >
> >package MyApp::Controller::Foo;
> >
> >use base qw(MyApp::ControllerBase::Chains);
> >
> >__PACKAGE__->config(object_chains = [ qw(id name email) ]);
> >
> >sub id ...
> >sub name ...
> >sub email ...
> >
> >Now, when Catalyst creates the Controller::Foo instance the
> >stuff after the
> >component method will create Controller::Foo::Id, ::Name,
> >::Email - Catalyst
> >will automatically pick this up (the same way it picks up the
> >sub-models
> >created by e.g. Model::DBIC::Schema) and will load the
> >Foo/Id.pm etc. files
> >afterwards -if- they exist.
> >
> >That way you'll get /foo/id/edit, /foo/name/edit etc. actions
> >which can be
> >passed happily to $c->uri_for without ambiguity, and still have minimal
> >repeated code.
> >
> >(Disclaimer: code typed straight into mail. probably at least
> >one typo or
> >thinko lurking in there)
> >
> >If people like this approach, I could write it up as an advent
> >entry ...
> >
>
> Well, it may seem cute, but I am worried about long-term maintenance of this
> approach : if two years later somebody has to change anything in that setup,
> without knowing as much about Catalyst internals as you do Matt, then it
> could be quite hard for them to understand what is going on.
Which is why I provided a full explanation of the technique, such as could be
put into comments in the classes involved so in two years the maintenance
programmer opens the file and finds a complete description of the mechanisms :)
> The original Catalyst design of URL-method mappings was quite obvious to
> understand (Local, Global, Regex, etc.). Then came the chained actions, that
> gave us much more flexibility and reuse, but require quite a bit of reading
> and experiment to really understand them. Now if we add even more indirection
> levels, it will make it even harder to follow.
>
> Two days ago at the French Perl Workshop somebody mentioned that Ruby on
> Rails has a notion of global, centralized dispatch table. Apache also has a
> convenient way to centralize the URL mappings, with or
> directives. As far as I know, Catalyst does not yet have any
> similar dispatch mechanism, but maybe that would be an interesting evolution
> path to investigate ?
You can already do that.
All the attributes can be assigned from controller config, as shown above.
So in MyApp.pm
__PACKAGE__->config(
Controller::Foo => { action => { bar => { Path => '/some/path' } } }
);
is identical to having :Path(/some/path) on the 'sub bar'. So we -can- do
things globally if we really want to.
But having self-contained controllers was an intentional design decision in
order to allow for improved code re-use - my base class trickery can be
written once and shared between projects, and in fact Reaction will include
a number of Catalyst::Controller subclasses designed for just this sort of
usage - a general admin interface one that scaffolds a full CRUD system, a
basic one-table CRUD controller and a simpler one-table 'list and view actions
only' controller.
Most large-scale Catalyst projects that Shadowcat is currently helping clients
with are already using base classes and connect-the-dots approaches like this
to maximise code re-use across their architecture (and were doing so before
we got involved); where this stuff then reflects out to apache configs there's
invariably either a nightmare nest of Include directives or a TT setup that
generates the appropriate httpd.conf chunks in order to get round the
limitation of a single global config tree.
So, on the whole the rails/httpd.conf approach might be superficially simpler
for small projects, but really doesn't scale the way the currently available
Catalyst approaches do. Additional levels of indirection is a normal part of
refactoring for re-use; liberal use of commen
Re: [Catalyst] PathPart help
On Nov 17, 2007, at 6:40 AM, Matt S Trout wrote: On Fri, Nov 16, 2007 at 01:50:03PM -0500, Jason Kohles wrote: I keep planning to dig into the dispatcher and figure out how to implement this (and multiple PathParts), but never enough TUITs... I intentionally -didn't- implement this when I wrote Chained; as soon as you do that the $c->uri_for($action, ...) syntax becomes ambiguous and a whole host of other problems crop up. Hmm, I hadn't dug into it far enough to discover those issues, I still feel like I'm just on the edge of really understanding how the dispatcher works, but not quite there yet. :) What I'd do instead is - package MyApp::Controller::Foo; use base qw(MyApp::ControllerBase::Chains); __PACKAGE__->config(object_chains = [ qw(id name email) ]); sub id ... sub name ... sub email ... Now, when Catalyst creates the Controller::Foo instance the stuff after the component method will create Controller::Foo::Id, ::Name, ::Email - Catalyst will automatically pick this up (the same way it picks up the sub- models created by e.g. Model::DBIC::Schema) and will load the Foo/Id.pm etc. files afterwards -if- they exist. That way you'll get /foo/id/edit, /foo/name/edit etc. actions which can be passed happily to $c->uri_for without ambiguity, and still have minimal repeated code. That's pretty slick, you just saved me a whole lot of repetitive typing on my current project... -- Jason Kohles, RHCA RHCDS RHCE [EMAIL PROTECTED] - http://www.jasonkohles.com/ "A witty saying proves nothing." -- Voltaire ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] PathPart help
>-Message d'origine-
>De : Matt S Trout [mailto:[EMAIL PROTECTED]
>Envoyé : samedi, 17. novembre 2007 12:40
[ snip ]
>
>What I'd do instead is -
>
>package MyApp::ControllerBase::HasObject;
>
>sub has_object :PathPart('') :CaptureArgs(0)
>sub edit :Chained('has_user') :PathPart('edit') :Args(0)
>
>package MyApp::ControllerBase::ChainBase;
>
>__PACKAGE__->mk_accessors(qw(object_chains));
>
>__PACKAGE__->config(object_chains => []);
>
>sub COMPONENT {
> my $new = shift->NEXT::COMPONENT(@_);
> foreach my $chain (@{$new->object_chains}) { # commented
>using example 'id'
>my $action = $self->action_for($chain); # Catalyst::Action
>for /foo/id
>my $pkg = ref($new).'::'.ucfirst($chain); # 'id' ->
>Controller::Foo::Id
>{
> no strict 'refs';
> @{"${pkg}::ISA"} = 'MyApp::ControllerBase::HasObject'; #
>inject base class
>}
># Set :Chained('id') on Controller::Foo::Id->has_user
>$pkg->config(actions => { has_object => { Chained =>
>$action->reverse } });
> }
> return $new;
>}
>
>package MyApp::Controller::Foo;
>
>use base qw(MyApp::ControllerBase::Chains);
>
>__PACKAGE__->config(object_chains = [ qw(id name email) ]);
>
>sub id ...
>sub name ...
>sub email ...
>
>Now, when Catalyst creates the Controller::Foo instance the
>stuff after the
>component method will create Controller::Foo::Id, ::Name,
>::Email - Catalyst
>will automatically pick this up (the same way it picks up the
>sub-models
>created by e.g. Model::DBIC::Schema) and will load the
>Foo/Id.pm etc. files
>afterwards -if- they exist.
>
>That way you'll get /foo/id/edit, /foo/name/edit etc. actions
>which can be
>passed happily to $c->uri_for without ambiguity, and still have minimal
>repeated code.
>
>(Disclaimer: code typed straight into mail. probably at least
>one typo or
>thinko lurking in there)
>
>If people like this approach, I could write it up as an advent
>entry ...
>
Well, it may seem cute, but I am worried about long-term maintenance of this
approach : if two years later somebody has to change anything in that setup,
without knowing as much about Catalyst internals as you do Matt, then it could
be quite hard for them to understand what is going on.
The original Catalyst design of URL-method mappings was quite obvious to
understand (Local, Global, Regex, etc.). Then came the chained actions, that
gave us much more flexibility and reuse, but require quite a bit of reading and
experiment to really understand them. Now if we add even more indirection
levels, it will make it even harder to follow.
Two days ago at the French Perl Workshop somebody mentioned that Ruby on Rails
has a notion of global, centralized dispatch table. Apache also has a
convenient way to centralize the URL mappings, with or
directives. As far as I know, Catalyst does not yet have any
similar dispatch mechanism, but maybe that would be an interesting evolution
path to investigate ?
Regards, Laurent Dami
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] PathPart help
On Fri, Nov 16, 2007 at 01:50:03PM -0500, Jason Kohles wrote:
> On Nov 16, 2007, at 11:11 AM, Christopher H. Laco wrote:
>
> >Interesting twist. Reminds me of the RHOX stuff..
> >
> >users/id/
> >users/name/
> >
> >etc. Damnit. Now you have me thinking again. That setup is a great
> >reason to keep REST and web controllers seperated. :/
> >
>
>
> The only problem with it is that I would love to be able to do this,
> but so far I haven't come up with a reasonable way to say 'chain from
> any of these controllers'. i.e. it would be really nice to be able
> to do this:
>
> sub base : Chained('/') PathPart('users') CaptureArgs(0) { }
>
> sub id : Chained('base') PathPart('id') CaptureArgs(1) { }
> sub name : Chained('base') PathPart('name') CaptureArgs(1) { }
> sub email : Chained('base') PathPart('email') CaptureArgs(1) { }
>
> And then be able to base later controllers on any of these, something
> like:
>
> sub edit : Chained('id','name','email') PathPart('edit') Args(0) { }
>
> I would also be nice to be able to have chain elements that didn't
> correspond to URLs, so you could do something like this:
>
> sub has_user : Chained('id|name|email') NoPathPart CaptureArgs(0) { }
> sub edit : Chained('has_user') PathPart('edit') Args(0) { }
>
>
> I keep planning to dig into the dispatcher and figure out how to
> implement this (and multiple PathParts), but never enough TUITs...
I intentionally -didn't- implement this when I wrote Chained; as soon as
you do that the $c->uri_for($action, ...) syntax becomes ambiguous and a
whole host of other problems crop up.
What I'd do instead is -
package MyApp::ControllerBase::HasObject;
sub has_object :PathPart('') :CaptureArgs(0)
sub edit :Chained('has_user') :PathPart('edit') :Args(0)
package MyApp::ControllerBase::ChainBase;
__PACKAGE__->mk_accessors(qw(object_chains));
__PACKAGE__->config(object_chains => []);
sub COMPONENT {
my $new = shift->NEXT::COMPONENT(@_);
foreach my $chain (@{$new->object_chains}) { # commented using example 'id'
my $action = $self->action_for($chain); # Catalyst::Action for /foo/id
my $pkg = ref($new).'::'.ucfirst($chain); # 'id' -> Controller::Foo::Id
{
no strict 'refs';
@{"${pkg}::ISA"} = 'MyApp::ControllerBase::HasObject'; # inject base class
}
# Set :Chained('id') on Controller::Foo::Id->has_user
$pkg->config(actions => { has_object => { Chained => $action->reverse } });
}
return $new;
}
package MyApp::Controller::Foo;
use base qw(MyApp::ControllerBase::Chains);
__PACKAGE__->config(object_chains = [ qw(id name email) ]);
sub id ...
sub name ...
sub email ...
Now, when Catalyst creates the Controller::Foo instance the stuff after the
component method will create Controller::Foo::Id, ::Name, ::Email - Catalyst
will automatically pick this up (the same way it picks up the sub-models
created by e.g. Model::DBIC::Schema) and will load the Foo/Id.pm etc. files
afterwards -if- they exist.
That way you'll get /foo/id/edit, /foo/name/edit etc. actions which can be
passed happily to $c->uri_for without ambiguity, and still have minimal
repeated code.
(Disclaimer: code typed straight into mail. probably at least one typo or
thinko lurking in there)
If people like this approach, I could write it up as an advent entry ...
--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Directorhttp://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/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] PathPart help
On 11/16/07, Jason Kohles <[EMAIL PROTECTED]> wrote:
> On Nov 16, 2007, at 11:11 AM, Christopher H. Laco wrote:
>
> sub has_user : Chained('id|name|email') NoPathPart CaptureArgs(0) { }
> sub edit : Chained('has_user') PathPart('edit') Args(0) { }
>
That NoPathPart you already have with an empty PathPart('').
--
Jonas
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] PathPart help
On Nov 16, 2007, at 11:11 AM, Christopher H. Laco wrote:
Interesting twist. Reminds me of the RHOX stuff..
users/id/
users/name/
etc. Damnit. Now you have me thinking again. That setup is a great
reason to keep REST and web controllers seperated. :/
The only problem with it is that I would love to be able to do this,
but so far I haven't come up with a reasonable way to say 'chain from
any of these controllers'. i.e. it would be really nice to be able
to do this:
sub base : Chained('/') PathPart('users') CaptureArgs(0) { }
sub id : Chained('base') PathPart('id') CaptureArgs(1) { }
sub name : Chained('base') PathPart('name') CaptureArgs(1) { }
sub email : Chained('base') PathPart('email') CaptureArgs(1) { }
And then be able to base later controllers on any of these, something
like:
sub edit : Chained('id','name','email') PathPart('edit') Args(0) { }
I would also be nice to be able to have chain elements that didn't
correspond to URLs, so you could do something like this:
sub has_user : Chained('id|name|email') NoPathPart CaptureArgs(0) { }
sub edit : Chained('has_user') PathPart('edit') Args(0) { }
I keep planning to dig into the dispatcher and figure out how to
implement this (and multiple PathParts), but never enough TUITs...
--
Jason Kohles, RHCA RHCDS RHCE
[EMAIL PROTECTED] - http://www.jasonkohles.com/
"A witty saying proves nothing." -- Voltaire
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] PathPart help
On Thu, Nov 15, 2007 at 11:47:34AM -0800, Les Fletcher wrote: > I have question about setting up PathPart's and Chaining. I am trying > to set something that has the following look: > > /namespace/ => This lists out a list of objects > /namespace/ => displays detail information about the object with the > numeric id= > /namespace//edit => brings up a form to edit object with numeric id= > /namespace/create => brings up a form to create a new object > > When the Chained actions are printed out everything looks fine, but when > I goto "/namespace/create" it matches the "/namespace/" view > action. Needless to say, there isn't an object with the numeric id of > "create." Try upgrading to absolute latest Catalyst, I'm sure somebody patched this. If that doesn't help, I'd suggest using /namespace/id//edit which is what I always use anyway, in case I need to change to string ids later (slightly obsessive future-proofing but I've long since decided it's not paranoia and the requirements changes -are- out to get me :). -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://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/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] PathPart help
Matt S Trout wrote: > On Thu, Nov 15, 2007 at 11:47:34AM -0800, Les Fletcher wrote: >> I have question about setting up PathPart's and Chaining. I am trying >> to set something that has the following look: >> >> /namespace/ => This lists out a list of objects >> /namespace/ => displays detail information about the object with the >> numeric id= >> /namespace//edit => brings up a form to edit object with numeric id= >> /namespace/create => brings up a form to create a new object >> >> When the Chained actions are printed out everything looks fine, but when >> I goto "/namespace/create" it matches the "/namespace/" view >> action. Needless to say, there isn't an object with the numeric id of >> "create." > > Try upgrading to absolute latest Catalyst, I'm sure somebody patched this. > > If that doesn't help, I'd suggest using > > /namespace/id//edit Interesting twist. Reminds me of the RHOX stuff.. users/id/ users/name/ etc. Damnit. Now you have me thinking again. That setup is a great reason to keep REST and web controllers seperated. :/ -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] PathPart help
On Nov 15, 2007, at 11:31 PM, Les Fletcher wrote:
That one seems to use as explicit "view" at the end of the url
instead of having the identifier be the last piece of the url.
To have one without the 'view', just use an empty PathPart like
'default' below...
The one problem with your design though, is the trouble with being
able to support either an id or an argument (like 'create') as the
second item in the field. Because of the problems with that, I
usually use an explicit 'id' part to identify where the id starts,
like so...
sub base : Chained('/') PathPart('namespace') CaptureArgs(0) { }
sub id : Chained('base') PathPart('id') CaptureArgs(1) {
my ( $self, $c, $id ) = @_;
$c->stash->{ 'object' } $c->model( 'MyModel' )->find( $id );
}
sub edit : Chained('id') PathPart('edit') Args(0) { }
sub view : Chained('id') PathPart('view') Args(0) { }
sub default : Chained('id') PathPart('') Args(0) {
my ( $self, $c ) = @_;
$c->forward( 'view' );
}
sub create : Chained('base') PathPart('create') Args(0) { }
This way things that you can do without a specific object (like
'create', 'list', 'search') just get chained to 'base', while things
that require an object ('edit', 'view', 'delete') get chained to 'id',
which is responsible for finding and stashing the object (I also
usually put the access control stuff there to determine if the user is
allowed to view/edit/delete that object.)
Peter Karman wrote:
Les Fletcher wrote on 11/15/07 1:47 PM:
I have question about setting up PathPart's and Chaining. I am
trying
to set something that has the following look:
/namespace/ => This lists out a list of objects
/namespace/ => displays detail information about the object
with the
numeric id=
/namespace//edit => brings up a form to edit object with numeric
id=
/namespace/create => brings up a form to create a new object
This controller implements that exact API:
http://search.cpan.org/~karman/Catalyst-Controller-Rose-0.04/lib/Catalyst/Controller/Rose/CRUD.pm
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
--
Jason Kohles, RHCA RHCDS RHCE
[EMAIL PROTECTED] - http://www.jasonkohles.com/
"A witty saying proves nothing." -- Voltaire
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] PathPart help
Les Fletcher wrote on 11/15/07 1:47 PM: > I have question about setting up PathPart's and Chaining. I am trying > to set something that has the following look: > > /namespace/ => This lists out a list of objects > /namespace/ => displays detail information about the object with the > numeric id= > /namespace//edit => brings up a form to edit object with numeric > id= > /namespace/create => brings up a form to create a new object > This controller implements that exact API: http://search.cpan.org/~karman/Catalyst-Controller-Rose-0.04/lib/Catalyst/Controller/Rose/CRUD.pm -- Peter Karman . http://peknet.com/ . [EMAIL PROTECTED] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] PathPart help
That one seems to use as explicit "view" at the end of the url instead of having the identifier be the last piece of the url. Peter Karman wrote: Les Fletcher wrote on 11/15/07 1:47 PM: I have question about setting up PathPart's and Chaining. I am trying to set something that has the following look: /namespace/ => This lists out a list of objects /namespace/ => displays detail information about the object with the numeric id= /namespace//edit => brings up a form to edit object with numeric id= /namespace/create => brings up a form to create a new object This controller implements that exact API: http://search.cpan.org/~karman/Catalyst-Controller-Rose-0.04/lib/Catalyst/Controller/Rose/CRUD.pm ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] PathPart help
I am using
__PACKAGE__->config->{ namespace } = 'foo';
sub obj_setup : PathPart('') CaptureArgs(1) {}
sub create_setup : PathPart('') CaptureArgs(0) {}
sub view : PathPart('') Chained('obj_setup') Args(0) {}
sub edit : PathPart('') Chained('obj_setup') Args(0) {}
sub create : PathPart('create') Chained('create_setup') Args(0) { }
The thing I don't understand is that when the Chained actions are
printed out, it gives me the correct actions as I would expect them.
The create one just doesn't get matched.
Les
Christopher H. Laco wrote:
Christopher H. Laco wrote:
Les Fletcher wrote:
I have question about setting up PathPart's and Chaining. I am trying
to set something that has the following look:
/namespace/ => This lists out a list of objects
/namespace/ => displays detail information about the object with the
numeric id=
/namespace//edit => brings up a form to edit object with numeric
id=
/namespace/create => brings up a form to create a new object
When the Chained actions are printed out everything looks fine, but when
I goto "/namespace/create" it matches the "/namespace/" view
action. Needless to say, there isn't an object with the numeric id of
"create."
I would like for Catalyst to try and match the explicit PathPart before
matching the wild card that is . Any thoughts on best ways to get
around this?
A couple of ways I thought of were:
I could make the view path be "/namespace//view," it seems a little
weird, but would be acceptable if need be.
I could have an action that matches "/namespace/*" and then forward to
the create action if "*" is "create" and to the view action other wise,
but this could limit my ability to further chain from here.
Catalyst just might not match the paths in a way that is conducive to
this, but just thought I'd throw this out there.
Les
http://use.perl.org/~LTjake/journal/31738
-=Chris
I use this exact setup, and I assume most do. How is your create
declared? sub create : Local {} ?
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] PathPart help
Les Fletcher wrote: > I have question about setting up PathPart's and Chaining. I am trying > to set something that has the following look: > > /namespace/ => This lists out a list of objects > /namespace/ => displays detail information about the object with the > numeric id= > /namespace//edit => brings up a form to edit object with numeric > id= > /namespace/create => brings up a form to create a new object > > When the Chained actions are printed out everything looks fine, but when > I goto "/namespace/create" it matches the "/namespace/" view > action. Needless to say, there isn't an object with the numeric id of > "create." > > I would like for Catalyst to try and match the explicit PathPart before > matching the wild card that is . Any thoughts on best ways to get > around this? > A couple of ways I thought of were: > > I could make the view path be "/namespace//view," it seems a little > weird, but would be acceptable if need be. > > I could have an action that matches "/namespace/*" and then forward to > the create action if "*" is "create" and to the view action other wise, > but this could limit my ability to further chain from here. > > Catalyst just might not match the paths in a way that is conducive to > this, but just thought I'd throw this out there. > > Les http://use.perl.org/~LTjake/journal/31738 -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] PathPart help
Ashley Pond V wrote: > That is really cool and answers something I've wanted to do for a long > time (let the user define the URI to customize a package). I have a > question. Using the PathPrefix seems to work as advertised but it does > not replace the default path. > > So, in a test I just did, MyApp::Controller::Article with > __PACKAGE__->config( path => 'a' ) gives the expected, new, result at > path "/a" but also still responds at "/article." Seems like this is not > DWIW or M. (I'm using the sample sub in the post, not the trunk code). > > The others replace correctly though(?). > > /a == /article > but > /a/id works while /article/id fails as I'd like. > > -Ashley Someone correct me if I'm wrong, but I don't believe PathPrefix is in a release yet...only current source, which is probably going to be 5.9. I still, as of the latest release on CPAN, have to add the PathPrefix attr parsing sub. Good old LTjake. That post has save me many hours of crying...over, and over with chained. -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] PathPart help
Now the difference with the path prefix stuff is lost to me. This fixes the root namespace issue (seems obvious now) and works like the path prefix is supposed to. __PACKAGE__->config( namespace => 'a' ) What finer point am I missing? You're right, it's not in the release yet, just the trunk. On Nov 15, 2007, at 1:03 PM, Christopher H. Laco wrote: Ashley Pond V wrote: That is really cool and answers something I've wanted to do for a long time (let the user define the URI to customize a package). I have a question. Using the PathPrefix seems to work as advertised but it does not replace the default path. So, in a test I just did, MyApp::Controller::Article with __PACKAGE__->config( path => 'a' ) gives the expected, new, result at path "/a" but also still responds at "/article." Seems like this is not DWIW or M. (I'm using the sample sub in the post, not the trunk code). The others replace correctly though(?). /a == /article but /a/id works while /article/id fails as I'd like. -Ashley Someone correct me if I'm wrong, but I don't believe PathPrefix is in a release yet...only current source, which is probably going to be 5.9. I still, as of the latest release on CPAN, have to add the PathPrefix attr parsing sub. Good old LTjake. That post has save me many hours of crying...over, and over with chained. -=Chris ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/ [EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] PathPart help
That is really cool and answers something I've wanted to do for a
long time (let the user define the URI to customize a package). I
have a question. Using the PathPrefix seems to work as advertised but
it does not replace the default path.
So, in a test I just did, MyApp::Controller::Article with __PACKAGE__-
>config( path => 'a' ) gives the expected, new, result at path "/a"
but also still responds at "/article." Seems like this is not DWIW or
M. (I'm using the sample sub in the post, not the trunk code).
The others replace correctly though(?).
/a == /article
but
/a/id works while /article/id fails as I'd like.
-Ashley
On Nov 15, 2007, at 12:07 PM, Christopher H. Laco wrote:
http://use.perl.org/~LTjake/journal/31738
-=Chris
I use this exact setup, and I assume most do. How is your create
declared? sub create : Local {} ?
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] PathPart help
Christopher H. Laco wrote:
> Les Fletcher wrote:
>> I have question about setting up PathPart's and Chaining. I am trying
>> to set something that has the following look:
>>
>> /namespace/ => This lists out a list of objects
>> /namespace/ => displays detail information about the object with the
>> numeric id=
>> /namespace//edit => brings up a form to edit object with numeric
>> id=
>> /namespace/create => brings up a form to create a new object
>>
>> When the Chained actions are printed out everything looks fine, but when
>> I goto "/namespace/create" it matches the "/namespace/" view
>> action. Needless to say, there isn't an object with the numeric id of
>> "create."
>>
>> I would like for Catalyst to try and match the explicit PathPart before
>> matching the wild card that is . Any thoughts on best ways to get
>> around this?
>> A couple of ways I thought of were:
>>
>> I could make the view path be "/namespace//view," it seems a little
>> weird, but would be acceptable if need be.
>>
>> I could have an action that matches "/namespace/*" and then forward to
>> the create action if "*" is "create" and to the view action other wise,
>> but this could limit my ability to further chain from here.
>>
>> Catalyst just might not match the paths in a way that is conducive to
>> this, but just thought I'd throw this out there.
>>
>> Les
>
> http://use.perl.org/~LTjake/journal/31738
>
> -=Chris
I use this exact setup, and I assume most do. How is your create
declared? sub create : Local {} ?
signature.asc
Description: OpenPGP digital signature
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] PathPart help
I have question about setting up PathPart's and Chaining. I am trying to set something that has the following look: /namespace/ => This lists out a list of objects /namespace/ => displays detail information about the object with the numeric id= /namespace//edit => brings up a form to edit object with numeric id= /namespace/create => brings up a form to create a new object When the Chained actions are printed out everything looks fine, but when I goto "/namespace/create" it matches the "/namespace/" view action. Needless to say, there isn't an object with the numeric id of "create." I would like for Catalyst to try and match the explicit PathPart before matching the wild card that is . Any thoughts on best ways to get around this? A couple of ways I thought of were: I could make the view path be "/namespace//view," it seems a little weird, but would be acceptable if need be. I could have an action that matches "/namespace/*" and then forward to the create action if "*" is "create" and to the view action other wise, but this could limit my ability to further chain from here. Catalyst just might not match the paths in a way that is conducive to this, but just thought I'd throw this out there. Les ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
