Mailing List Archive: Catalyst: Users

Request paths - rejoining Chained actions together.

Index | Next | Previous | View Threaded

bobtfish at bobtfish

May 9, 2008, 5:00 AM

Post #1 of 14 (496 views)
Permalink

Request paths - rejoining Chained actions together.

Hi

I'm building quite a complex app, which has a number of ways of
locating things, and I want to be able to rejoin chains..

Some example URLs:

/volume/*/track/*/format/*
/track/*format/*

This becomes:

sub tracksequence : Chained('/') PathPart('track') CaptureArgs(1) {}

sub volume : Chained('/') PathPart('volume') CaptureArgs(1) {}
sub trackonvolume : Chained('volume') CaptureArgs(1) {}

sub format : Chained('tracksequence', 'trackonvolume') PathPart
('format') Args(1) {}

But this doesn't work...

So what I've got instead is:

sub formattracksequence : Chained('tracksequence') PathPart('format')
Args(1) { $c->forward('format'); }
sub formattrackonvolume: Chained('tracksequence', 'trackonvolume')
PathPart('format') Args(1) { $c->forward('format') }
sub format : Private {}

Which works fine.. However, this is just a subset of my URL
complexity, and I have *multiple* points where I want to be able to
chain one function into two (or more) chains..

My actual URLs look like /volume/track/*/format/*bitrate/*/
someoperation or track/*/format/*bitrate/*/someoperation

and having to maintain two seperate sets of chains is pretty painful..

Is there any sane way of doing this? Am I missing something obvious?

Cheers
Tom

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

jshirley at gmail

May 9, 2008, 7:55 AM

Post #2 of 14 (480 views)
Permalink

Re: Request paths - rejoining Chained actions together. [In reply to]

On Fri, May 9, 2008 at 5:00 AM, Tomas Doran <bobtfish[at]bobtfish.net> wrote:
> Hi
>
> I'm building quite a complex app, which has a number of ways of locating
> things, and I want to be able to rejoin chains..
>
> Some example URLs:
>
> /volume/*/track/*/format/*
> /track/*format/*
>
> This becomes:
>
> sub tracksequence : Chained('/') PathPart('track') CaptureArgs(1) {}
>
> sub volume : Chained('/') PathPart('volume') CaptureArgs(1) {}
> sub trackonvolume : Chained('volume') CaptureArgs(1) {}
>
> sub format : Chained('tracksequence', 'trackonvolume') PathPart('format')
> Args(1) {}
>
> But this doesn't work...
>
> So what I've got instead is:
>
> sub formattracksequence : Chained('tracksequence') PathPart('format')
> Args(1) { $c->forward('format'); }
> sub formattrackonvolume: Chained('tracksequence', 'trackonvolume')
> PathPart('format') Args(1) { $c->forward('format') }
> sub format : Private {}
>
> Which works fine.. However, this is just a subset of my URL complexity, and
> I have *multiple* points where I want to be able to chain one function into
> two (or more) chains..
>
> My actual URLs look like /volume/track/*/format/*bitrate/*/someoperation or
> track/*/format/*bitrate/*/someoperation
>
> and having to maintain two seperate sets of chains is pretty painful..
>
> Is there any sane way of doing this? Am I missing something obvious?
>
> Cheers
> Tom
>

It sounds like your actions are capture arguments, rather than
separate midpoints (since they're working on the same resource,
anyway).

If you have someoperation as a CaptureArg, and stick that away in the
stash to perform the action later in the chain, you should get what
you want.

-J

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

bobtfish at bobtfish

May 10, 2008, 12:10 AM

Post #3 of 14 (469 views)
Permalink

Re: Request paths - rejoining Chained actions together. [In reply to]

On 9 May 2008, at 15:55, J. Shirley wrote:

> On Fri, May 9, 2008 at 5:00 AM, Tomas Doran <bobtfish[at]bobtfish.net>
> wrote:
>> Some example URLs:
>>
>> /volume/*/track/*/format/*
>> /track/*format/*
>> <snip>
>> sub format : Chained('tracksequence', 'trackonvolume') PathPart
>> ('format')
>> Args(1) {}
>>
>> But this doesn't work...
>>
>> <snip>
>
> It sounds like your actions are capture arguments, rather than
> separate midpoints (since they're working on the same resource,
> anyway).
>
> If you have someoperation as a CaptureArg, and stick that away in the
> stash to perform the action later in the chain, you should get what
> you want.
>

I see what you mean, but that means I have to do a reasonable amount
of error handling myself, as there are only a few sets of actions
which are valid..

Also, the number of arguments to access a resource can vary..

My URLs are of the form:

/thing/<canonical_identifier>/further/*/chained/*/things
/thing/other_identifier_p1/*/other_identifier_p2/*/further/*/chained/
*/things

Looking up by the canonical identifier, and another identifier are
also actually different operations, so it'd be nice to be able to
split them, but more to the point what you suggested just won't work,
as I can't just say CaptureArgs(4) - as there can be different
numbers of arguments for various points to join..

If I was to hack some code (and tests) up which supported my
originally suggested syntax ( Chained('sub1', 'sub2') for joining
chains), what would anyone feel about it?

Cheers
Tom

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

dbix-class at trout

May 10, 2008, 7:12 AM

Post #4 of 14 (468 views)
Permalink

Re: Request paths - rejoining Chained actions together. [In reply to]

On Fri, May 09, 2008 at 01:00:07PM +0100, Tomas Doran wrote:
> Hi
>
> I'm building quite a complex app, which has a number of ways of
> locating things, and I want to be able to rejoin chains..
>
> Some example URLs:
>
> /volume/*/track/*/format/*
> /track/*format/*
>
> This becomes:
>
> sub tracksequence : Chained('/') PathPart('track') CaptureArgs(1) {}
>
> sub volume : Chained('/') PathPart('volume') CaptureArgs(1) {}
> sub trackonvolume : Chained('volume') CaptureArgs(1) {}

sub format :Chained PathPart('format') Args(1) {}

Inherit that into both controllers.

__PACKAGE__->config(actions => { format => { Chained => 'tracksequence' } });

in one controller, and 'trackonvolume' in the other.

Then you have two format endpoints but one 'sub format'.

Problem solved.

> But this doesn't work...
>
> So what I've got instead is:
>
> sub formattracksequence : Chained('tracksequence') PathPart('format')
> Args(1) { $c->forward('format'); }
> sub formattrackonvolume: Chained('tracksequence', 'trackonvolume')
> PathPart('format') Args(1) { $c->forward('format') }
> sub format : Private {}
>
> Which works fine.. However, this is just a subset of my URL
> complexity, and I have *multiple* points where I want to be able to
> chain one function into two (or more) chains..
>
> My actual URLs look like /volume/track/*/format/*bitrate/*/
> someoperation or track/*/format/*bitrate/*/someoperation
>
> and having to maintain two seperate sets of chains is pretty painful..
>
> Is there any sane way of doing this? Am I missing something obvious?
>
> Cheers
> Tom
>
>
> _______________________________________________
> List: Catalyst[at]lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/

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

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

pagaltzis at gmx

May 10, 2008, 7:26 AM

Post #5 of 14 (465 views)
Permalink

Re: Request paths - rejoining Chained actions together. [In reply to]

* Tomas Doran <bobtfish[at]bobtfish.net> [2008-05-10 09:25]:
> If I was to hack some code (and tests) up which supported my
> originally suggested syntax ( Chained('sub1', 'sub2') for
> joining chains), what would anyone feel about it?

You could no longer make `uri_for` work in the general case if
you did that.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

bobtfish at bobtfish

May 11, 2008, 12:58 AM

Post #6 of 14 (454 views)
Permalink

Re: Request paths - rejoining Chained actions together. [In reply to]

On 10 May 2008, at 15:12, Matt S Trout wrote:

> On Fri, May 09, 2008 at 01:00:07PM +0100, Tomas Doran wrote:
> sub format :Chained PathPart('format') Args(1) {}
>
> Inherit that into both controllers.
>
> __PACKAGE__->config(actions => { format => { Chained =>
> 'tracksequence' } });
>
> in one controller, and 'trackonvolume' in the other.
>
> Then you have two format endpoints but one 'sub format'.
>
> Problem solved.
>

Aha, much neater / more D.R.Y. thanks. :)

However, this does mean I now have 3 packages (a base class, and two
controllers), where before I had one file..

The actual controller code for all of this stuff is pretty small (as
it's just asking the model stuff, and stashing it at each stage), and
it will be much less visually clear what the hell is going on to have
it spread across three packages..

Is there any semantic problem with the idea of being able to chain a
sub to multiple places? (E.g.sub format : Chained('tracksequence')
Chained('trackonvolume') PathPart('format') Args(1) {}) ?

After hacking a round a little yesterday, I've got the syntax as
suggested above kinda working, and I'll probably keep fiddling with
it unless someone can give me some good reasons why having multiple
Chained attributes should be forbidden (as, lets face it - splitting
my code into 3 packages and inheriting *in this case* is, a hack to
get round Chained not playing how I'd like it to)..

Cheers
Tom

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

bobtfish at bobtfish

May 11, 2008, 2:01 AM

Post #7 of 14 (456 views)
Permalink

Re: Re: Request paths - rejoining Chained actions together. [In reply to]

On 10 May 2008, at 15:26, Aristotle Pagaltzis wrote:

> * Tomas Doran <bobtfish[at]bobtfish.net> [2008-05-10 09:25]:
>> If I was to hack some code (and tests) up which supported my
>> originally suggested syntax ( Chained('sub1', 'sub2') for
>> joining chains), what would anyone feel about it?
>
> You could no longer make `uri_for` work in the general case if
> you did that.

Aha! I had a feeling the reason that someone didn't do that already
is that there was a compelling reason to not do so - I just hadn't
thought about it hard enough..

I'll shut up and go away now, thanks guys :)

t0m

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

pagaltzis at gmx

May 11, 2008, 7:17 AM

Post #8 of 14 (452 views)
Permalink

Re: Request paths - rejoining Chained actions together. [In reply to]

* Tomas Doran <bobtfish[at]bobtfish.net> [2008-05-11 10:05]:
> However, this does mean I now have 3 packages (a base class,
> and two controllers), where before I had one file..

There’s nothing stopping you from putting them all in a single
file. :-)

> (as, lets face it - splitting my code into 3 packages and
> inheriting *in this case* is, a hack to get round Chained not
> playing how I'd like it to)..

Au contraire. Inheritance is part of the language. Why should
Catalyst invent a limited Catalyst-specific parallel mechanism?

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

dbix-class at trout

May 11, 2008, 7:18 AM

Post #9 of 14 (452 views)
Permalink

Re: Re: Request paths - rejoining Chained actions together. [In reply to]

On Sun, May 11, 2008 at 10:01:47AM +0100, Tomas Doran wrote:
>
> On 10 May 2008, at 15:26, Aristotle Pagaltzis wrote:
>
> >* Tomas Doran <bobtfish[at]bobtfish.net> [2008-05-10 09:25]:
> >>If I was to hack some code (and tests) up which supported my
> >>originally suggested syntax ( Chained('sub1', 'sub2') for
> >>joining chains), what would anyone feel about it?
> >
> >You could no longer make `uri_for` work in the general case if
> >you did that.
>
> Aha! I had a feeling the reason that someone didn't do that already
> is that there was a compelling reason to not do so - I just hadn't
> thought about it hard enough..

That's a compelling reason not to rush in, but I still think it's possible.

The trick is to provide some way to disambiguate - either a preferred path
(which could vary between controllers, say) or maybe passing an arrayref
of action objects indicating the precise chain.

Have a think about it and see about an RFC if you're still interested; the
trouble is the extra bookkeeping rapidly gets us to the point where the
base class + N controllers approach isn't really any more typing anyway,
which is why I've not given this much time yet.

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

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

bobtfish at bobtfish

May 11, 2008, 5:11 PM

Post #10 of 14 (448 views)
Permalink

Re: Re: Request paths - rejoining Chained actions together. [In reply to]

On 11 May 2008, at 15:17, Aristotle Pagaltzis wrote:

> * Tomas Doran <bobtfish[at]bobtfish.net> [2008-05-11 10:05]:
>> However, this does mean I now have 3 packages (a base class,
>> and two controllers), where before I had one file..
>
> There�s nothing stopping you from putting them all in a single
> file. :-)

Now, I may be going mad - but this doesn't play for me..

Make a test app, and add the following to the bottom of lib/MyApp/
Controller/Root.pm:
package MyApp::Controller::Foo;
use base qw(Catalyst::Controller);

sub one : Chained('/') PathPart('one') {}

sub two : Chained('one') PathPart('two') {}

sub end : Chained('two') PathPart('end') Args(0) {}

Start the test server.. You don't get any notification about
'MyApp::Controller::Foo' being loaded, and you don't see the chained
actions.

Comment out the 'package' line, and it works as expected. Split
things into files, and it works as expected.

Is this a known / documented bug / limitation?

>
>> (as, lets face it - splitting my code into 3 packages and
>> inheriting *in this case* is, a hack to get round Chained not
>> playing how I'd like it to)..

And so, as noted - I need to split to 3 files, which is less than
optimum.

> Au contraire. Inheritance is part of the language. Why should
> Catalyst invent a limited Catalyst-specific parallel mechanism?

I see what you're saying, but I'd consider re-use of controllers as
orthogonal to their dispatch patterns.

To be fair, if I can stuff the 3 relevant controllers into the same
file, then it's all good, and I'm a happy man - however as-is I can't..

Cheers
Tom

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

bobtfish at bobtfish

May 11, 2008, 5:20 PM

Post #11 of 14 (446 views)
Permalink

Re: Re: Request paths - rejoining Chained actions together. [In reply to]

On 11 May 2008, at 15:18, Matt S Trout wrote:

> On Sun, May 11, 2008 at 10:01:47AM +0100, Tomas Doran wrote:
>>
>> Aha! I had a feeling the reason that someone didn't do that already
>> is that there was a compelling reason to not do so - I just hadn't
>> thought about it hard enough..
>
> That's a compelling reason not to rush in, but I still think it's
> possible.

I didn't really mean it wasn't possible - just that it was harder
than just a bit of fiddling with C::DT::Chained (the hardest part of
which, to make it 'look like' it's working, for the simple case, is
getting the debug table right ;) )

> The trick is to provide some way to disambiguate - either a
> preferred path
> (which could vary between controllers, say) or maybe passing an
> arrayref
> of action objects indicating the precise chain.

The idea of uri_for having a method of passing uri_for hints which
are only valid in one context (i.e. Chained) kinda smells to me, but
then implicit behind the scenes magic also scares me... Hmm, I'll
have a think / play some more.

> Have a think about it and see about an RFC if you're still
> interested; the
> trouble is the extra bookkeeping rapidly gets us to the point where
> the
> base class + N controllers approach isn't really any more typing
> anyway,
> which is why I've not given this much time yet.

That's totally fair, I'll see how $ork's problem space expands in the
next couple of iterations of the code, as I think this is a problem
that I'm going to see again when I start exposing more complex
objects - if that gets to a point of being painful with inheritance,
then I'll re-visit this.

Cheers
Tom

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

dbix-class at trout

May 28, 2008, 10:44 PM

Post #12 of 14 (253 views)
Permalink

Re: Re: Request paths - rejoining Chained actions together. [In reply to]

On Mon, May 12, 2008 at 01:11:48AM +0100, Tomas Doran wrote:
>
> On 11 May 2008, at 15:17, Aristotle Pagaltzis wrote:
>
> >* Tomas Doran <bobtfish[at]bobtfish.net> [2008-05-11 10:05]:
> >>However, this does mean I now have 3 packages (a base class,
> >>and two controllers), where before I had one file..
> >
> >There’s nothing stopping you from putting them all in a single
> >file. :-)
>
> Now, I may be going mad - but this doesn't play for me..
>
> Make a test app, and add the following to the bottom of lib/MyApp/
> Controller/Root.pm:
> package MyApp::Controller::Foo;

That's not going to work.

That's not how my example worked.,

As I said before, Catalyst will treat the namespace corresponding to the
file and any -subnamespaces- as components to load.

Which is why my example was more like Controller/Foo.pm containing
MyApp::Controller::Foo::Child[123].

We don't go round ranbdomly instnatiating every package we find in any
file under Model/View/Controller - *that* would be a bug. Not doing so is
a feature :)

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

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

bobtfish at bobtfish

May 29, 2008, 2:07 AM

Post #13 of 14 (253 views)
Permalink

Re: Re: Request paths - rejoining Chained actions together. [In reply to]

On 29 May 2008, at 06:44, Matt S Trout wrote:
> As I said before, Catalyst will treat the namespace corresponding
> to the
> file and any -subnamespaces- as components to load.
>
> Which is why my example was more like Controller/Foo.pm containing
> MyApp::Controller::Foo::Child[123].
>
> We don't go round ranbdomly instnatiating every package we find in any
> file under Model/View/Controller - *that* would be a bug. Not doing
> so is
> a feature :)

Aha, as usual, I knew I was missing some essential & obvious point
when trying to do that, but didn't really have time to scrobble the
source.

And as usual, you made all clear, thanks mst.

Is this clarified in the documentation (as I missed it), and if not
where is the appropriate place for it to live? If it's not documented
then I'll write up a doc patch...

Cheers
Tom

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

dbix-class at trout

May 30, 2008, 3:14 AM

Post #14 of 14 (244 views)
Permalink

Re: Re: Request paths - rejoining Chained actions together. [In reply to]

On Thu, May 29, 2008 at 10:07:50AM +0100, Tomas Doran wrote:
>
> On 29 May 2008, at 06:44, Matt S Trout wrote:
> >As I said before, Catalyst will treat the namespace corresponding
> >to the
> >file and any -subnamespaces- as components to load.
> >
> >Which is why my example was more like Controller/Foo.pm containing
> >MyApp::Controller::Foo::Child[123].
> >
> >We don't go round ranbdomly instnatiating every package we find in any
> >file under Model/View/Controller - *that* would be a bug. Not doing
> >so is
> >a feature :)
>
> Aha, as usual, I knew I was missing some essential & obvious point
> when trying to do that, but didn't really have time to scrobble the
> source.
>
> And as usual, you made all clear, thanks mst.
>
> Is this clarified in the documentation (as I missed it), and if not
> where is the appropriate place for it to live? If it's not documented
> then I'll write up a doc patch...

I'd vote for putting the package behaviour in setup_component and the
general approach in the cookbook.

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

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com