Best way to validate Chained actions?

I'm trying to figure out the best[*] way to validate Chained
actions  
at various points along the action chain.  By validate, I
mean "check  
if the action should proceed or bomb out."  Validation
is not the  
same as authentication; I may be logged in but I may not
have  
permissions to do certain things.  It may also mean
proceeding is not  
possible because there is some bad data introduced in one of
the  
links.  Let's take a simple chain where I want to check
whether or  
not a user can perform basic CRUD type things on our data.
Given two paths:

/bigthing/<id>
/bigthing/<id>/edit

I was building this chain as:

load-bigthing-data -> check_read -> view
                                  -> check_update ->
edit

Now this gets convoluted when I want to act on sub part of
bigthing.   
Say we have action paths that resemble something like:

/bigthing/<id>/smallthing/<id_2>
/bigthing/<id>/smallthing/<id_2>/edit

So presumably, I'd try to chain like:

load-bigthing-data -> check_read ->
load-smallthing-data -> view  
(that's ok)
                                                         
->  
check_update -> edit (bad)

check_update is chained between check_read and edit, so I
either need  
to create a new (duplicated) check_update for smallthing
edit or  
preferably come up with something better.

I wasn't very happy with the permissions validation being
wedged in  
as a link in this action chain.  I think a better solution
might be  
to use attributes and custom Actions, but I'm still trying
to wrap my  
head around that possibility.  The best solution would bomb
out  
before doing any more processing in further actions (i.e.
doing it as  
part of an 'end' action is not preferable).

Thoughts?

thanks,
Micah

[*] Best = laziest to code + cleanest to extent + easiest to
understand


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

Micah Jaffe wrote:
> I'm trying to figure out the best[*] way to validate
Chained actions at
> various points along the action chain.  By validate, I
mean "check if
> the action should proceed or bomb out." 
Validation is not the same as
> authentication; I may be logged in but I may not have
permissions to do
> certain things.  It may also mean proceeding is not
possible because
> there is some bad data introduced in one of the links. 
Let's take a
> simple chain where I want to check whether or not a
user can perform
> basic CRUD type things on our data.
> Given two paths:
> 
> /bigthing/<id>
> /bigthing/<id>/edit
> 
> I was building this chain as:
> 
> load-bigthing-data -> check_read -> view
>                                  -> check_update
-> edit
> 
> Now this gets convoluted when I want to act on sub part
of bigthing. 
> Say we have action paths that resemble something like:
> 
> /bigthing/<id>/smallthing/<id_2>
> /bigthing/<id>/smallthing/<id_2>/edit

This brings me to a related question that always bugs the
hell out of me
about using Chained.

Right now, if you use PathPrefix
(http://use.
perl.org/~LTjake/journal/31738), you end up with a
controller that can be subclassed and renamed without
changing any code.

In other words, ::BigThing could be renamed to MyThing, the
chained uri
follow suit from /bigthing/ to /smallthing/ and everyone is
happy.

The minute you add a child class into the mix (SmallThing),
you have to
 hardcode Chained in SmallThing with the name/private/path
pointing to
BigThing.

Now, renaming BigThing breaks SmallThing. That sucks and I
have no idea
how to fix that to make subclassing/renaming with a
parent/child level
of Chained happy.

Sure, you could put all of the SmallThing chained methods
into the
BigThing class, but now the method names in that class for
the
SmallThing actions dirty up the class somewhat.

If any of that made sense, I'm sorry. 
It just bugs me that the elegantness of using PathPrefix in
Chained goes
to hell when you want to attach another child level into the
mix.

It also, just may be too earily in the am for me to thing
without coffee.

-=Chris



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

On Thu, Sep 13, 2007 at 08:41:24AM -0400, Christopher H.
Laco wrote:
> Micah Jaffe wrote:
> > I'm trying to figure out the best[*] way to
validate Chained actions at
> > various points along the action chain.  By
validate, I mean "check if
> > the action should proceed or bomb out." 
Validation is not the same as
> > authentication; I may be logged in but I may not
have permissions to do
> > certain things.  It may also mean proceeding is
not possible because
> > there is some bad data introduced in one of the
links.  Let's take a
> > simple chain where I want to check whether or not
a user can perform
> > basic CRUD type things on our data.
> > Given two paths:
> > 
> > /bigthing/<id>
> > /bigthing/<id>/edit
> > 
> > I was building this chain as:
> > 
> > load-bigthing-data -> check_read -> view
> >                                  ->
check_update -> edit
> > 
> > Now this gets convoluted when I want to act on sub
part of bigthing. 
> > Say we have action paths that resemble something
like:
> > 
> > /bigthing/<id>/smallthing/<id_2>
> > /bigthing/<id>/smallthing/<id_2>/edit
> 
> This brings me to a related question that always bugs
the hell out of me
> about using Chained.
> 
> Right now, if you use PathPrefix
> (http://use.
perl.org/~LTjake/journal/31738), you end up with a
> controller that can be subclassed and renamed without
changing any code.
> 
> In other words, ::BigThing could be renamed to MyThing,
the chained uri
> follow suit from /bigthing/ to /smallthing/ and
everyone is happy.
> 
> The minute you add a child class into the mix
(SmallThing), you have to
>  hardcode Chained in SmallThing with the
name/private/path pointing to
> BigThing.

Somebody needs to implement :Chained(../something).

Given the number of things I'm working on atm, it's unlikely
to be me.

Patches welcome 

-- 
      Matt S Trout       Need help with your Catalyst or
DBIx::Class project?
   Technical Director    Want a managed development or
deployment platform?
 Shadowcat Systems Ltd.  Contact mst (at)
shadowcatsystems.co.uk for a quote
http://chainsawblues.vo
x.com/                    http://www.shadowcat.co.u
k/ 

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