Questions about chained actions, endpoints, etc.

Hey guys, this very well may be due purely to my lack of
experience in this
matter, but I'm having trouble getting chained actions
working the way I
WANT them to work and I'm suspicious the way I want them to
work is not the
way they're intended to work.

Here's the situation: I want the application to have public
paths like
these:

    /admin              List of all existing
"books" you can look at
    /admin/add          Form (FormBuilder) for adding a new
book
    /admin/99           Detailed output of data on book 99
    /admin/99/edit      Form (FormBuilder) for editing book
99 data
    /admin/99/delete    Form for confirming deletion of book
99

Looking at the Catalyst:ispatchT
ype::Chained documentation, it's not
obvious (to me, anyway) how I should go about this.

The way I see it, /admin should be handled by a:
    
    package Foo::Controller::Admin;
    sub index : private {...}

and /admin/add should be handled by a:

    sub add : Local Form {...}

So, how exactly would someone suggest I set up the chained
handlers for the
other paths? I had something like this:

    sub detail :PathPart('admin') Chained('/') Args(1)
{...}
        
And that worked for the /admin/99 path, but nothing I can
muster up seems
to match the /admin/99/{edit,delete} paths. 

Any thoughts from those more experienced than me?

-- 
fozziodynamics.com is Doran L. Barton, president/CTO,
Iodynamics LLC
Iodynamics: IT and Web services by Linux/Open Source
specialists
 "Dealers will hear car talk at noon"
    -- Headline seen in newspaper

_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/

This is the same layout I have for my chained actions, and I
went 
through the same "huh?" phase as well.

You seem to be on the right track so far.  Here is a quick
copy / paste 
/ hack job of my layout adapted to your examples.  Won't go
in to too 
much detail since I am busy at work, so let me know if this
needs 
clarified further.

In Foo::Controller::Admin (left off "Form" attrib
in examples, just 
showing the chain layout)...


# Not chained, responds to /admin
sub index : Private { ... }

# Not chained, responds to /admin/add
sub sub add : Local { ... }

# Captures a book id in the chain for use by further chained
actions
# You would validate the id, grab it from the model, and put
it in
# the stash here
sub get_book : PathPart('admin') Chained CaptureArgs(1)
{
   my ( $self, $c, $id) = _;
   ...
}

# Chain endpoint for viewing book, responds to /admin/99
sub view : PathPart('') Chained('get_book') Args(0) { ... }

# Chain endpoint for editing book, responds to
/admin/99/edit
sub edit : Chained('get_book') Args(0) { ... }

# Chain endpoint for deleting book, responds to
/admin/99/delete
sub delete : Chained('get_book') Args(0) { ... }


Hope that helps!

Danny Warren

Doran L. Barton wrote:
> Hey guys, this very well may be due purely to my lack
of experience in this
> matter, but I'm having trouble getting chained actions
working the way I
> WANT them to work and I'm suspicious the way I want
them to work is not the
> way they're intended to work.
> 
> Here's the situation: I want the application to have
public paths like
> these:
> 
>     /admin              List of all existing
"books" you can look at
>     /admin/add          Form (FormBuilder) for adding a
new book
>     /admin/99           Detailed output of data on book
99
>     /admin/99/edit      Form (FormBuilder) for editing
book 99 data
>     /admin/99/delete    Form for confirming deletion of
book 99
> 
> Looking at the Catalyst:ispatchT
ype::Chained documentation, it's not
> obvious (to me, anyway) how I should go about this.
> 
> The way I see it, /admin should be handled by a:
>     
>     package Foo::Controller::Admin;
>     sub index : private {...}
> 
> and /admin/add should be handled by a:
> 
>     sub add : Local Form {...}
> 
> So, how exactly would someone suggest I set up the
chained handlers for the
> other paths? I had something like this:
> 
>     sub detail :PathPart('admin') Chained('/') Args(1)
{...}
>         
> And that worked for the /admin/99 path, but nothing I
can muster up seems
> to match the /admin/99/{edit,delete} paths. 
> 
> Any thoughts from those more experienced than me?
> 
> 
> 
>
------------------------------------------------------------
------------
> 
> _______________________________________________
> List: Catalystlists.rawmode.org
> Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
> Dev site: http://dev.catalyst.per
l.org/

_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/

A couple of clarifications:

1) I typo'd 'sub sub' below in the 'add' action, whoops!

2) In my example, I should have used 'detail' as the action
instead of 
'view', to match your layout ('view' is what I use).

3) I think the general confusion on all of this, and I
didn't wrap my 
head around this when I read the Chained perldoc at first
either (even 
though reading it again, it makes sense) is how the
'Chained' attribute 
behaves.  A general rule of thumb I keep in my head is (and
this doesn't 
apply in all situations and special cases, but stays true
for most 
normal chain layouts I have used)...

When dealing with 'CaptureArgs' type methods, the 'Chained'
attribute 
refers to parts of the URI path.

When dealing with 'Args' type endpoint actions, the
'Chained' attribute 
refers to the 'CaptureArgs' method we want to chain off of,
and has 
nothing to do with the URI path.

Danny Warren


Danny Warren wrote:
> This is the same layout I have for my chained actions,
and I went 
> through the same "huh?" phase as well.
> 
> You seem to be on the right track so far.  Here is a
quick copy / paste 
> / hack job of my layout adapted to your examples. 
Won't go in to too 
> much detail since I am busy at work, so let me know if
this needs 
> clarified further.
> 
> In Foo::Controller::Admin (left off "Form"
attrib in examples, just 
> showing the chain layout)...
> 
> 
> # Not chained, responds to /admin
> sub index : Private { ... }
> 
> # Not chained, responds to /admin/add
> sub sub add : Local { ... }
> 
> # Captures a book id in the chain for use by further
chained actions
> # You would validate the id, grab it from the model,
and put it in
> # the stash here
> sub get_book : PathPart('admin') Chained
CaptureArgs(1)
> {
>   my ( $self, $c, $id) = _;
>   ...
> }
> 
> # Chain endpoint for viewing book, responds to
/admin/99
> sub view : PathPart('') Chained('get_book') Args(0) {
... }
> 
> # Chain endpoint for editing book, responds to
/admin/99/edit
> sub edit : Chained('get_book') Args(0) { ... }
> 
> # Chain endpoint for deleting book, responds to
/admin/99/delete
> sub delete : Chained('get_book') Args(0) { ... }
> 
> 
> Hope that helps!
> 
> Danny Warren
> 
> Doran L. Barton wrote:
>> Hey guys, this very well may be due purely to my
lack of experience in 
>> this
>> matter, but I'm having trouble getting chained
actions working the way I
>> WANT them to work and I'm suspicious the way I want
them to work is 
>> not the
>> way they're intended to work.
>>
>> Here's the situation: I want the application to
have public paths like
>> these:
>>
>>     /admin              List of all existing
"books" you can look at
>>     /admin/add          Form (FormBuilder) for
adding a new book
>>     /admin/99           Detailed output of data on
book 99
>>     /admin/99/edit      Form (FormBuilder) for
editing book 99 data
>>     /admin/99/delete    Form for confirming
deletion of book 99
>>
>> Looking at the Catalyst:ispatchT
ype::Chained documentation, it's not
>> obvious (to me, anyway) how I should go about
this.
>>
>> The way I see it, /admin should be handled by a:
>>         package Foo::Controller::Admin;
>>     sub index : private {...}
>>
>> and /admin/add should be handled by a:
>>
>>     sub add : Local Form {...}
>>
>> So, how exactly would someone suggest I set up the
chained handlers 
>> for the
>> other paths? I had something like this:
>>
>>     sub detail :PathPart('admin') Chained('/')
Args(1) {...}
>>         And that worked for the /admin/99 path, but
nothing I can 
>> muster up seems
>> to match the /admin/99/{edit,delete} paths.
>> Any thoughts from those more experienced than me?
>>
>>
>>
>>
------------------------------------------------------------
------------
>>
>> _______________________________________________
>> List: Catalystlists.rawmode.org
>> Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
>> Searchable archive: 
>> http://www.mail-
archive.com/catalystlists.rawmode.org/
>> Dev site: http://dev.catalyst.per
l.org/
> 
> _______________________________________________
> List: Catalystlists.rawmode.org
> Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
> Dev site: http://dev.catalyst.per
l.org/
> 
> 

_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/

Danny, 

Thanks for your reply. I finally had that epiphany right
before your
message came through.

The part I was not understanding was that the argument to
the Chained()
action is the private path name:

    # Handles /admin/*
    sub book_detail : PathPart('admin') Chained('/') Args(1)
{...}

    # Handler 1 of 2 for /admin/*/{edit,delete}
    sub book_link : PathPart('admin') Chained('/')
CaptureArgs(1) {...}

    sub edit : PathPart Chained('book_detail') Args(0)
{...}

I wasn't grasping that "minor detail" that the
edit() function needed to be 

    sub edit : PathPart Chained('admin') Args(0) {...}

Thanks! Now on to the next brick wall. 

-=Fozz

-- 
fozziodynamics.com is Doran L. Barton, president/CTO,
Iodynamics LLC
Iodynamics: IT and Web services by Linux/Open Source
specialists
 "This evening at 7 P.M. there will be a hymn sing in
the park across from
  the Church. Bring a blanket and come prepared to
sin."
    -- Seen in a church bulletin

_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/

Now try combining all that with using Chained('.') to spread
the chain 
across controllers!  (Which is really damned cool, and I use
it to split 
out my model relations in to chained controllers and actions
with and 
get clean uris).

Hint on how to do this (since I see that come up a lot on
the list as well).


In Catalyst::Controller::Admin...

# See previous example for index, add, view, edit and delete
actions 
related to the "Admin" controller

# Add a CaptureArgs method to hook our chain up to the child
Admin::Foo
# subcontroller
# NOTE: I am sure you could do some more interesting things
here, but I
# prefer to keep all the model interactions and stuff in the
real
# controller and just use this as a hook
sub foo : Chained('admin') CaptureArgs(0)
{
   my ( $self, $c ) = _;
}


In Catalyst::Controller::Admin::Foo...

# Chain endpoint for adding a related foo to a book
# Responds to /admin/[id]/foo/add
sub add : Chained('.') Args(0) { ... }

# Captures a foo id in the chain that is related to
# the book we already have in the chain from earlier
sub get_foo : PathPart('') Chained('.') CaptureArgs(1)
{
   my ( $self, $c, $id) = _;
   ... # Grab the book from the stash, use it to get the
related foo
       # and put THAT in the stash, etc
}

# Chain endpoint for viewing a foo related to a book
# Responds to /admin/[id]/foo/[id]/
sub display : PathPart('') Chained('get_foo') Args(0) { ...
}

# Chain endpoint for editing a foo related to a book
# Responds to /admin/[id]/foo/[id]/edit
sub edit : Chained('get_foo') Args(0) { ... }

# Chain endpoint for deleting a foo related to a book
# Responds to /admin/[id]/foo/[id]/delete
sub delete : Chained('get_foo') Args(0) { ... }


Keeps your relations, controllers and uri lyaout nice and
clean.

I have seen discussion here previously that Chained('.') is
a confusing 
way to express what is going on - but once you wrap your
head around the 
"Chained() in a Args method is for referring to
CaptureArgs methods not 
uri paths" thing, it starts to make a lot more sense
and feels natural.

Hope all this was interesting to *somebody* ;)

Danny Warren

Doran L. Barton wrote:
> Danny, 
> 
> Thanks for your reply. I finally had that epiphany
right before your
> message came through.
> 
> The part I was not understanding was that the argument
to the Chained()
> action is the private path name:
> 
>     # Handles /admin/*
>     sub book_detail : PathPart('admin') Chained('/')
Args(1) {...}
> 
>     # Handler 1 of 2 for /admin/*/{edit,delete}
>     sub book_link : PathPart('admin') Chained('/')
CaptureArgs(1) {...}
> 
>     sub edit : PathPart Chained('book_detail') Args(0)
{...}
> 
> I wasn't grasping that "minor detail" that
the edit() function needed to be 
> 
>     sub edit : PathPart Chained('admin') Args(0) {...}
> 
> Thanks! Now on to the next brick wall. 
> 
> -=Fozz
> 
> 
> 
>
------------------------------------------------------------
------------
> 
> _______________________________________________
> List: Catalystlists.rawmode.org
> Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
> Dev site: http://dev.catalyst.per
l.org/

_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/

Doran L. Barton wrote:
> The part I was not understanding was that the argument
to the Chained()
> action is the private path name:

Well, I thought the sentence

  Possible values are absolute and relative private action
paths[...]

in Catalyst:ispatchT
ype::Chained POD for the 'Chained' attribute would
make it clear that it doesn't want public URI parts.

.phaylon

_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/