On Tue, Feb 15, 2011 at 10:28 PM, Eden Cardim <[email protected]> wrote:
> >>>>> "will" == will trillich <[email protected]> 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} = > $c->model('Foo')->search({%params}); > > # in page() > $c->stash->{paged_rs} = > $c->stash->{rs}->search({}, {page => $p, rows => $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) = @_; > $c->stash->{rs}->create({ %more_params }) > } > > sub related_items :Chained('list') PathPart('related') CaptureArgs(0) { > my($self, $c) = @_; > $c->stash->{rs} = $c->stash->{rs}->related_resultset(''); > } > > sub related_page :Chained('related_items') PathPart('page') Args(0) { > my($self, $c) = @_; > $c->forward('page'); > } > > sub related_csv :Chained('related_items') PathPart('csv') Args(0) { > my($self, $c) = @_; > $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=rows, p=page, o=order. 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 = delete( $c->req->params->{$key} )* to prevent double-handling? Are there best-practices out there for this? == *...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
_______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
