[Catalyst] Sanity Check -- requesting feedback on chaining approach

will trillich will.trillich at serensoft.com
Wed Feb 16 15:17:59 GMT 2011


On Tue, Feb 15, 2011 at 10:28 PM, Eden Cardim <edencardim at gmail.com> wrote:

> >>>>> "will" =3D=3D will trillich <will.trillich at serensoft.com> writes:
>
>    will> package MyApp::Controller::Xyzzy;
>    will> sub base     : Chained         PathPart('xyzzy') CaptureArgs(0)
> {  }
>    will>   sub list   : Chained('base') PathPart('')      CaptureArgs(0)
> {  }
>    will>     sub page : Chained('list') PathPart('')             Args(0)
> {  }
>    will>     sub csv  : Chained('list') PathPart('csv')          Args(0)
> {  }
>    will>   sub item   : Chained('base') PathPart('')      CaptureArgs(1)
> {  }
>    will>     sub view : Chained('item') PathPart('')             Args(0)
> {  }
>
> Yes, this will work:
>
> # in list()
> $c->stash->{rs} =3D
>  $c->model('Foo')->search({%params});
>
> # in page()
> $c->stash->{paged_rs} =3D
>  $c->stash->{rs}->search({}, {page =3D> $p, rows =3D> $r});
>
> ...if that's what you're asking.
>
> Other interesting things you can do:
>
> sub add_item :Chained('list') PathPart('add') Args(0) {
>    my($self, $c) =3D @_;
>    $c->stash->{rs}->create({ %more_params })
> }
>
> sub related_items :Chained('list') PathPart('related') CaptureArgs(0) {
>    my($self, $c) =3D @_;
>    $c->stash->{rs} =3D $c->stash->{rs}->related_resultset('');
> }
>
> sub related_page :Chained('related_items') PathPart('page') Args(0) {
>    my($self, $c) =3D @_;
>    $c->forward('page');
> }
>
> sub related_csv :Chained('related_items') PathPart('csv') Args(0) {
>    my($self, $c) =3D @_;
>    $c->forward('csv');
> }
>
> Assuming %params in list() was a simple key/value map, add_items() is
> going to use those, in addition to whatever's in %more_params, which is
> cool because if you change the criteria in list(), it propagates
> everywhere else as well. Plus, you reuse the page/csv implementation
> easily. The combination of chained DBIC resultsets and catalyst chains
> is very similar to curried functions (I believe that's what the initial
> design goal was).
>

Excellent.* Catalyst chaining is awesome. Especially *related_items*, very
sweet.

The next question is, what's an elegant way to separate pager-params from
search-params? Page-params are always query_params, and search-params are
*usually* body_params ...but not always. What we're trying now is having
page-params be one letter: r=3Drows, p=3Dpage, o=3Dorder. A database field =
should
be far more descriptive than a single character, so that's our "line in the
sand". Or should we just *$param =3D delete( $c->req->params->{$key} )* to
prevent double-handling?

Are there best-practices out there for this?

=3D=3D

*...except our search-form is different from our entry-form. For example, we
let the user choose a range of dates which asks for two values (closed_begin
to closed_end) to search for a value in a single field (closed).

-- =

The first step towards getting somewhere is to decide that you are not going
to stay where you are.  -- J.P.Morgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110216/a1b24=
105/attachment.htm


More information about the Catalyst mailing list