[Catalyst] Catalyst-Manual now on git
Thanks to frew++, Catalyst-Manual is now no longer on svn and has moved to shadowcat's[1] git hosting. You can get a copy of the manual with the tutorial attached. Grab a fork with: git clone catag...@git.shadowcat.co.uk:Catalyst-Manual If you have patches, please contact this list with patches, or join #catalyst-dev on irc.perl.org for further instructions. If this is not practical for you you can also grab a copy from http://search.cpan.org/perldoc?Catalyst::Manual then it's a mater of downloading and untarring the source, then: $ git init $ git add * $ git commit -m 'initial import' # time passes ... stuff gets edited $ git diff patch.diff and send the patch.diff file to this list or talk to us on IRC as above (IRC is preferred in general). ___ 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/
Re: [Catalyst] Sanity Check -- requesting feedback on chaining approach
On Tue, Feb 15, 2011 at 10:28 PM, Eden Cardim edencar...@gmail.com wrote:
will == will trillich will.trill...@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} =
$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: 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/
Re: [Catalyst] Sanity Check -- requesting feedback on chaining approach
On Tue, 15 Feb 2011, will trillich wrote:
Does this seem like a best practice? Comments welcome.
Personally, my take on best practices for chaining is basically make sane
RESTful URIs.
I like to name my non-public chain point with private subs, and I like
my end points to be descriptive. So given that, I'd probably do
something like:
package MyApp::Controller::Xyzzy;
sub _set_xyzzy : Chained PathPart('xyzzy') CaptureArgs(0) { }
sub list : Chained('_set_xyzzy') PathPart('') Args(0){ }
# CSV dispatch based on Accept header, not URI!
sub _set_item : Chained('_set_xyzzy') PathPart('') CaptureArgs(1) { }
sub item : Chained('item') PathPart('') Args(0){ }
Although nowadays I've started using CX::Routes, which lets me _not_
name the subs themselves. I actually like this, since the subroutine
names don't participate in routing when you use chaining.
-dave
/*
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
*/
___
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/
Re: [Catalyst] Sanity Check -- requesting feedback on chaining approach
On Wed, Feb 16, 2011 at 11:08 AM, Dave Rolsky auta...@urth.org wrote:
On Tue, 15 Feb 2011, will trillich wrote:
package MyApp::Controller::Xyzzy;
sub _set_xyzzy : Chained PathPart('xyzzy') CaptureArgs(0) {
}
sub list : Chained('_set_xyzzy') PathPart('') Args(0){
}
# CSV dispatch based on Accept header, not URI!
sub _set_item : Chained('_set_xyzzy') PathPart('') CaptureArgs(1) {
}
sub item : Chained('item') PathPart('') Args(0){
}
Hmm. Curious about the inline comment there -- how do you do CSV based on
accept-header?
--
The first step towards getting somewhere is to decide that you are not going
to stay where you are. -- J.P.Morgan
___
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/
