> On Sat, Oct 17, 2009 at 12:50 PM, Aristotle Pagaltzis <pagaltzis@gmx.de>wrote:
> > * iain <iainhubbard@googlemail.com> [2009-10-16 17:30]:
> > > until we did this we had boilerplate validation at the top
> > > of all the local actions.
> >
> > ++
> >
> > Bill, in another thread you asked me for an example of how
> > Chained helps make things like complex auth checks more DRY.
> > I've been meaning to respond with an example out of my $job
> > codebase, but until I get around to it, here's your hands-on
> > example of something it'd buy your codebase immediately. :-)
>
> I meant to respond about that. Perhaps I'm missing something,
> but the chained example works great if there multiple actions
> that need to get at that "Foo" object. They can all chain back
> to the same root which validates the id and then fetches the
> Foo object with that id and stuffs it into the stash.
Exactly.
> But, its often the case (well, my case) that there's only *one*
> action that fetches Foo, but there's also single actions for
> find()ing a number of other objects. If I'm following the
> chained example correctly, then there would be root for each --
> Foo, Bar, Baz, and so on each running basically the same
> validation.
OK, that's a situation in which Chained indeed won't help (for
this particular aspect of the task).
> I suppose the root can be written in a way to fetch many
> different object types by inspecting the current action and
> thus the fetch for Foo, Bar, Baz, etc. objects could all have
> the same root of the chain.
No no no, that's not what I was suggesting. That's no good. If
you need to contort the code into unnatural structures, then
either you're not using Chained right or it's not the right tool.
Chained is good, but it's not end in itself; it's good because it
helps simplify your code, not just because.
> If I have many actions that do $c->model( $whatever )->find(
> $id ) and I want to validate id doesn't it seems like find()
> (or really search_rs() ) would be the method to override?
Yes, that would indeed be better in your case.
> Perhaps a better approach would be add a "safe_find()" as J.
> Shirley suggested, but what good are methods if you don't
> override them. ;)
That depends on several a lot of very subtle considerations. Does
that method get called internally by its framework? Do they
depend on its precise semantics? How transparent is your new
interface, in general? If the overridden method's semantics
change in a future framework version (adding back-compatible
features, most likely), will you have an easy way to provide
those new features to your own code also, or will your overridden
interface make it impossible or difficult?
After a few mildly painful experiences, I have become a bit gun
shy about overriding things, particularly for making them "more
powerful", and when in doubt, I would avoid it. For some kinds of
making things safer, though, overriding is the better choice.
(Yours might be such a case.) But it needs a lot of deliberation.
Just adding a different method is much less vagarious.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.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/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Posts
