Mailing List Archive: Catalyst: Dev

RT #36209: convert internal path seperators for clarity

Index | Next | Previous | View Threaded

brian.cassidy at nald

May 28, 2008, 6:45 AM

Post #1 of 14 (3417 views)
Permalink

RT #36209: convert internal path seperators for clarity

On behalf of "KONOBI <konobi [at] cpan>":

convert internal path seperators for clarity

This had been talked about before, but should ticket it up.

There is a confusion in general with users, especially new ones, about
the difference between an internal path and a uri. We had talked about
switching it out so that internal paths would use ":" as a seperator
instead of "/", but allow both for back-compat.

I reckon the change in code should be reasonably small, some tests
changed. The big winner would be to change all the docs/tutorials over
afterwards.

--

The original RT ticket can be found here:

http://rt.cpan.org/Ticket/Display.html?id=36209

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

dbix-class at trout

May 29, 2008, 4:57 AM

Post #2 of 14 (3293 views)
Permalink

Re: RT #36209: convert internal path seperators for clarity [In reply to]

On Wed, May 28, 2008 at 10:45:13AM -0300, Brian Cassidy wrote:
> On behalf of "KONOBI <konobi [at] cpan>":
>
> convert internal path seperators for clarity
>
> This had been talked about before, but should ticket it up.
>
> There is a confusion in general with users, especially new ones, about
> the difference between an internal path and a uri. We had talked about
> switching it out so that internal paths would use ":" as a seperator
> instead of "/", but allow both for back-compat.

What I've never quite worked out is why nobody confuses URIs and template
paths,. but they do confuse the private path.

: seems reasonable, though I do wonder why we can't just use :: and stop
lc'ing things so it becomes

$c->forward('Foo::bar') for MyApp::Controller::Foo::bar?

--
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
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

jshirley at gmail

May 29, 2008, 9:35 AM

Post #3 of 14 (3296 views)
Permalink

Re: RT #36209: convert internal path seperators for clarity [In reply to]

On Thu, May 29, 2008 at 4:57 AM, Matt S Trout <dbix-class [at] trout> wrote:
> On Wed, May 28, 2008 at 10:45:13AM -0300, Brian Cassidy wrote:
>> On behalf of "KONOBI <konobi [at] cpan>":
>>
>> convert internal path seperators for clarity
>>
>> This had been talked about before, but should ticket it up.
>>
>> There is a confusion in general with users, especially new ones, about
>> the difference between an internal path and a uri. We had talked about
>> switching it out so that internal paths would use ":" as a seperator
>> instead of "/", but allow both for back-compat.
>
> What I've never quite worked out is why nobody confuses URIs and template
> paths,. but they do confuse the private path.
>
> : seems reasonable, though I do wonder why we can't just use :: and stop
> lc'ing things so it becomes
>
> $c->forward('Foo::bar') for MyApp::Controller::Foo::bar?
>

That seems by far to make the most sense, and really should clarify things.

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

hdp at pobox

May 31, 2008, 5:58 AM

Post #4 of 14 (3288 views)
Permalink

Re: RT #36209: convert internal path seperators for clarity [In reply to]

On Thu, May 29, 2008 at 09:35:57AM -0700, J. Shirley wrote:
> > $c->forward('Foo::bar') for MyApp::Controller::Foo::bar?
> >
>
> That seems by far to make the most sense, and really should clarify things.

It will un-clarify any controller that changes config->{namespace}.

Are there any other cases where private path names don't match $package ::
$methodname?

hdp.

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

dbix-class at trout

Jun 1, 2008, 12:12 AM

Post #5 of 14 (3286 views)
Permalink

Re: RT #36209: convert internal path seperators for clarity [In reply to]

On Sat, May 31, 2008 at 08:58:38AM -0400, Hans Dieter Pearcey wrote:
> On Thu, May 29, 2008 at 09:35:57AM -0700, J. Shirley wrote:
> > > $c->forward('Foo::bar') for MyApp::Controller::Foo::bar?
> > >
> >
> > That seems by far to make the most sense, and really should clarify things.
>
> It will un-clarify any controller that changes config->{namespace}.

Well ... not really. I think it would simply ignore config->{namespace}.

Perhaps better would be 'Foo->bar', then the code basically becomes

my $action = $c->controller(split('->', $str)[0])
->action_for(split('->', $str)[1]);

I can see only two reasons for wanting to change the private path:

(1) in Root.pm to provide base /begin /auto and /end actions for the whole app
(2) to split a large controller up into several but still $c->forward('foo')

Maybe we should look at finding a way to handle these cases that's saner.

I'm pretty sure the private namespace is basically useless for anything else
(yes, uri_for uses it, but any code that uses uri_for without either an action
object or an absolute URL is basically broken and the new action_uri/whatever
methods shouldn't need it at all).

> Are there any other cases where private path names don't match $package ::
> $methodname?

Not that I can think of.

--
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
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

peter at peknet

Jun 2, 2008, 6:33 AM

Post #6 of 14 (3277 views)
Permalink

Re: RT #36209: convert internal path seperators for clarity [In reply to]

On 06/01/2008 02:12 AM, Matt S Trout wrote:

> I'm pretty sure the private namespace is basically useless for anything else
> (yes, uri_for uses it, but any code that uses uri_for without either an action
> object or an absolute URL is basically broken and the new action_uri/whatever
> methods shouldn't need it at all).
>

Just to be clear, you're saying:

$c->uri_for('foo');

is "basically broken"?

--
Peter Karman . peter [at] peknet . http://peknet.com/

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

jjn1056 at yahoo

Jun 2, 2008, 1:11 PM

Post #7 of 14 (3279 views)
Permalink

Re: RT #36209: convert internal path seperators for clarity [In reply to]

--- On Sun, 6/1/08, Matt S Trout <dbix-class [at] trout> wrote:

> From: Matt S Trout <dbix-class [at] trout>
> Subject: Re: [Catalyst-dev] RT #36209: convert internal path seperators for clarity
> To: "Development of the elegant MVC web framework" <catalyst-dev [at] lists>
> Date: Sunday, June 1, 2008, 3:12 AM
> On Sat, May 31, 2008 at 08:58:38AM -0400, Hans Dieter
> Pearcey wrote:
> > On Thu, May 29, 2008 at 09:35:57AM -0700, J. Shirley
> wrote:
> > > > $c->forward('Foo::bar') for
> MyApp::Controller::Foo::bar?
> > > >
> > >
> > > That seems by far to make the most sense, and
> really should clarify things.
> >
> > It will un-clarify any controller that changes
> config->{namespace}.
>
> Well ... not really. I think it would simply ignore
> config->{namespace}.
>
> Perhaps better would be 'Foo->bar', then the
> code basically becomes
>
> my $action = $c->controller(split('->',
> $str)[0])
> ->action_for(split('->',
> $str)[1]);
>
> I can see only two reasons for wanting to change the
> private path:
>
> (1) in Root.pm to provide base /begin /auto and /end
> actions for the whole app
> (2) to split a large controller up into several but still
> $c->forward('foo')
>
> Maybe we should look at finding a way to handle these cases
> that's saner.

I've always felt iffy about namespace being part of the controller class in this way. The examples you gave (regarding /auto, etc and partitioning controllers) are the only ones I can think of as well. However I have to wonder if this is too much tying of information to a controller? I guess the fundamental question I have is if a controller should know it's namespace, or if that attribute should be assigned to it from from external class or process. From my thinking a controller class should only know enough about itself to work, everything else should be passed into it from the dispatcher or from some sort of adapter class that 'wraps' it for consumption via the dispatching mechanism. So I guess I am wondering if we are at the proper level of abstraction here?

_john napiorkowski

>
> I'm pretty sure the private namespace is basically
> useless for anything else
> (yes, uri_for uses it, but any code that uses uri_for
> without either an action
> object or an absolute URL is basically broken and the new
> action_uri/whatever
> methods shouldn't need it at all).
>
> > Are there any other cases where private path names
> don't match $package ::
> > $methodname?
>
> Not that I can think of.
>
> --
> 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
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

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

dbix-class at trout

Jun 2, 2008, 11:31 PM

Post #8 of 14 (3269 views)
Permalink

Re: RT #36209: convert internal path seperators for clarity [In reply to]

On Mon, Jun 02, 2008 at 08:33:33AM -0500, Peter Karman wrote:
>
>
> On 06/01/2008 02:12 AM, Matt S Trout wrote:
>
> > I'm pretty sure the private namespace is basically useless for anything else
> > (yes, uri_for uses it, but any code that uses uri_for without either an action
> > object or an absolute URL is basically broken and the new action_uri/whatever
> > methods shouldn't need it at all).
> >
>
> Just to be clear, you're saying:
>
> $c->uri_for('foo');
>
> is "basically broken"?

Yep. It uses the internal action namespace, not the URI, so it's not
really a relative URI and can easily fail when you refactor your app later.

Just don't use it.

--
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
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

dbix-class at trout

Jun 2, 2008, 11:34 PM

Post #9 of 14 (3291 views)
Permalink

Re: RT #36209: convert internal path seperators for clarity [In reply to]

On Mon, Jun 02, 2008 at 01:11:15PM -0700, John Napiorkowski wrote:
> I've always felt iffy about namespace being part of the controller class in this way. The examples you gave (regarding /auto, etc and partitioning controllers) are the only ones I can think of as well. However I have to wonder if this is too much tying of information to a controller? I guess the fundamental question I have is if a controller should know it's namespace, or if that attribute should be assigned to it from from external class or process. From my thinking a controller class should only know enough about itself to work, everything else should be passed into it from the dispatcher or from some sort of adapter class that 'wraps' it for consumption via the dispatching mechanism. So I guess I am wondering if we are at the proper level of abstraction here?

The controller uses the namespace when it calls register_actions; I think
that's correct since that's it telling the dispatcher where to add its
actions to the tree - or at least the controller should be able to supply
a default - it doesn't really seem wrong to me that Root.pm can specify that it
should by default attach its actions under /.

Post-setup it doesn't really need it at all; action_for uses it but that's
basically just a matter of convenience; no reason you couldn't add a
dispatcher API that looks up the controller to find the action rather than
looking up the namespace - and that's exactly what we'd need to build to
support Foo::Bar->baz style forwards anyway :)

--
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
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

jjn1056 at yahoo

Jun 3, 2008, 7:12 AM

Post #10 of 14 (3268 views)
Permalink

Re: RT #36209: convert internal path seperators for clarity [In reply to]

--- On Tue, 6/3/08, Matt S Trout <dbix-class [at] trout> wrote:

> From: Matt S Trout <dbix-class [at] trout>
> Subject: Re: [Catalyst-dev] RT #36209: convert internal path seperators for clarity
> To: jjn1056 [at] yahoo, "Development of the elegant MVC web framework" <catalyst-dev [at] lists>
> Date: Tuesday, June 3, 2008, 2:34 AM
> On Mon, Jun 02, 2008 at 01:11:15PM -0700, John Napiorkowski
> wrote:
> > I've always felt iffy about namespace being part
> of the controller class in this way. The examples you gave
> (regarding /auto, etc and partitioning controllers) are the
> only ones I can think of as well. However I have to wonder
> if this is too much tying of information to a controller? I
> guess the fundamental question I have is if a controller
> should know it's namespace, or if that attribute should
> be assigned to it from from external class or process. From
> my thinking a controller class should only know enough about
> itself to work, everything else should be passed into it
> from the dispatcher or from some sort of adapter class that
> 'wraps' it for consumption via the dispatching
> mechanism. So I guess I am wondering if we are at the
> proper level of abstraction here?
>
> The controller uses the namespace when it calls
> register_actions; I think
> that's correct since that's it telling the
> dispatcher where to add its
> actions to the tree - or at least the controller should be
> able to supply
> a default - it doesn't really seem wrong to me that
> Root.pm can specify that it
> should by default attach its actions under /.
>
> Post-setup it doesn't really need it at all; action_for
> uses it but that's
> basically just a matter of convenience; no reason you
> couldn't add a
> dispatcher API that looks up the controller to find the
> action rather than
> looking up the namespace - and that's exactly what
> we'd need to build to
> support Foo::Bar->baz style forwards anyway :)
>
> --
> 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
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

jjn1056 at yahoo

Jun 3, 2008, 8:09 AM

Post #11 of 14 (3263 views)
Permalink

Re: RT #36209: convert internal path seperators for clarity [In reply to]

Apologies for top posting, and apologies for sending so many blank responses to the list. I guess there is some strange incompatibility with my client or something, but for some reason this happens only on this list. I'll switch clients to something that won't cause this strange problem. My intended reply is below.

John Napiorkowski

--- On Tue, 6/3/08, Matt S Trout <dbix-class [at] trout> wrote:

> From: Matt S Trout <dbix-class [at] trout>
> Subject: Re: [Catalyst-dev] RT #36209: convert internal path seperators for clarity
> To: jjn1056 [at] yahoo, "Development of the elegant MVC web framework" <catalyst-dev [at] lists>
> Date: Tuesday, June 3, 2008, 2:34 AM
> On Mon, Jun 02, 2008 at 01:11:15PM -0700, John Napiorkowski
> wrote:
> > I've always felt iffy about namespace being part
> of the controller class in this way. The examples you gave
> (regarding /auto, etc and partitioning controllers) are the
> only ones I can think of as well. However I have to wonder
> if this is too much tying of information to a controller? I
> guess the fundamental question I have is if a controller
> should know it's namespace, or if that attribute should
> be assigned to it from from external class or process. From
> my thinking a controller class should only know enough about
> itself to work, everything else should be passed into it
> from the dispatcher or from some sort of adapter class that
> 'wraps' it for consumption via the dispatching
> mechanism. So I guess I am wondering if we are at the
> proper level of abstraction here?
>
> The controller uses the namespace when it calls
> register_actions; I think
> that's correct since that's it telling the
> dispatcher where to add its
> actions to the tree - or at least the controller should be
> able to supply
> a default - it doesn't really seem wrong to me that
> Root.pm can specify that it
> should by default attach its actions under /.

I guess I've just seen a lot of namespace abuse that my instinct is to severely reduce it's user accessibility. But I can't really think of something more elegant that does what it needs, ie everything you mentioned already :)

The types of abuse that I've seen typically play with namespace in base controllers that then get used in crazy multiply inheritances so that in the end you have no idea what's happening. Also I know sometimes $c->namespace gets used in controllers and views. I'm not sure if this should be an accepted practice or not.

>
> Post-setup it doesn't really need it at all; action_for
> uses it but that's
> basically just a matter of convenience; no reason you
> couldn't add a
> dispatcher API that looks up the controller to find the
> action rather than
> looking up the namespace - and that's exactly what
> we'd need to build to
> support Foo::Bar->baz style forwards anyway :)

That sounds so much saner to me.

>
> --
> 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
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

jgottshall at capwiz

Jun 4, 2008, 10:14 AM

Post #12 of 14 (3260 views)
Permalink

RE: RT #36209: convert internal path seperators forclarity [In reply to]

On Sunday, June 01, 2008 3:12 AM, Matt S Trout wrote:

> I'm pretty sure the private namespace is basically useless for
anything
> else (yes, uri_for uses it, but any code that uses uri_for without
> either an action object or an absolute URL is basically broken and the

> new action_uri/whatever methods shouldn't need it at all).

Trying to understand the implications here. Both Ash's[1] and
Aristotle's[2] recently-posted versions of an action_uri()-like method
take a private path as a key argument on which to look up the related
action. Is that not how you see action_uri working?

Jason

[1] http://lists.scsys.co.uk/pipermail/catalyst-dev/2008-May/001238.html
[2] http://lists.scsys.co.uk/pipermail/catalyst-dev/2008-May/001240.html

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

marcus at nordaaker

Jun 4, 2008, 12:00 PM

Post #13 of 14 (3254 views)
Permalink

Re: RT #36209: convert internal path seperators for clarity [In reply to]

On 3. juni. 2008, at 08.31, Matt S Trout wrote:

> Yep. It uses the internal action namespace, not the URI, so it's not
> really a relative URI and can easily fail when you refactor your app
> later.
>
> Just don't use it.

I strongly disagree that we can say it is broken. Of course, if you
think it's related to the external uri and not the controller you
will be surprised, but I don't think we can break backwards compat
lightly on this one. Saying 'doing that is broken' just won't do.

Marcus

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

dbix-class at trout

Jun 8, 2008, 10:29 AM

Post #14 of 14 (3205 views)
Permalink

Re: RT #36209: convert internal path seperators for clarity [In reply to]

On Wed, Jun 04, 2008 at 09:00:51PM +0200, Marcus Ramberg wrote:
> On 3. juni. 2008, at 08.31, Matt S Trout wrote:
>
> >Yep. It uses the internal action namespace, not the URI, so it's not
> >really a relative URI and can easily fail when you refactor your app
> >later.
> >
> >Just don't use it.
>
> I strongly disagree that we can say it is broken. Of course, if you
> think it's related to the external uri and not the controller you
> will be surprised, but I don't think we can break backwards compat
> lightly on this one. Saying 'doing that is broken' just won't do.

I'm not suggesting we can change the behaviour.

I'm just suggesting that the behaviour is so easily not DWIM that its usage
should be avoided, and the new action_uri stuff should do something more
sensible.

Basically, uri_for('foo') is on the same level as { foo => $req->param('foo') }
- it might do what you want at least some of the time, but it probably
doesn't mean what you think it means so in the general case it's safer not
to use it. uri_for($c->controller->action_for('foo')) and
{ foo => $c->req->params->{foo} } are both better.

--
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
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads