On Sun, May 4, 2008 at 11:58 AM, Zbigniew Lukasiak <[EMAIL PROTECTED]> wrote: > > On Sun, May 4, 2008 at 12:23 PM, luke saunders <[EMAIL PROTECTED]> wrote: > > > > On Sun, May 4, 2008 at 10:20 AM, Zbigniew Lukasiak <[EMAIL PROTECTED]> > wrote: > > > > > > On Sun, May 4, 2008 at 2:38 AM, luke saunders <[EMAIL PROTECTED]> wrote: > > > > I have started to write a Catalyst base controller for REST style > CRUD > > > > via DBIC. I have noticed that a number of other people have been > > > > working on or are thinking about working on something similar, most > > > > notabley J. Shirley who seems to be creating > > > > Catalyst::Controller::REST::DBIC::Item > > > > > (http://dev.catalystframework.org/svnweb/Catalyst/browse/Catalyst-Controller-REST-DBIC-Item/) > > > > and some chaps from a recent thread on this list (entitled > > > > "Dispatching with Chained vs HTTP method"). > > > > > > > > Ideally I would like to merge J. Shirley's effort into mine (or visa > > > > versa) along with anything that anyone else has. Basically I want to > > > > avoid ending up with a load of modules that all do the same thing. > > > > > > > > My effort is heavily based on something mst wrote a while ago, and > > > > since then I've ended up writing something very similar for every > > > > project I've worked on which indicates it's worth OSing. Essentially > > > > it is used like so: > > > > > > > > package MyApp::Controller::API::REST::CD; > > > > > > > > use base qw/Catalyst::Controller::REST::DBIC/; > > > > > > > > ... > > > > > > > > __PACKAGE__->config > > > > ( action => { setup => { PathPart => 'cd', Chained => > > > > '/api/rest/rest_base' } }, > > > > class => 'RestTestDB::CD', > > > > create_requires => ['artist', 'title', 'year' ], > > > > update_allows => ['title', 'year'] > > > > ); > > > > > > > > And this gets you the following endpoints to fire requests at: > > > > /api/rest/cd/create > > > > /api/rest/cd/id/[cdid]/update > > > > /api/rest/cd/id/[cdid]/delete > > > > /api/rest/cd/id/[cdid]/add_to_rel/[relation] > > > > /api/rest/cd/id/[cdid]/remove_from_rel/[relation] > > > > > > > > The full source is here: > > > > > http://lukesaunders.me.uk/dists/Catalyst-Controller-REST-DBIC-1.000000.tar.gz > > > > > > > > If you have a few moments please have a look, especially if you are > > > > working on something similar. Today I even wrote a test suite which > > > > has a test app and is probably the best place to look to see what it > > > > does. > > > > > > I've been planning for a more REST-like update to InstantCRUD for a > > > long time. My approach is a bit different because for validation and > > > for generating form's HTML I use HTML::Widget. I believe validation > > > is important and separate enough to have a separate package (and I > > > don't want to reinvent the wheel - so I use what is available at > > > CPAN). I also choose to generate the HTML - because I believe there > > > is too much logic (classes for errors, options from the database, > > > subforms from the database - see below) in it for the simplistic > > > Template::Toolkit language - an elegant solution for that could be > > > also a TT plugin. > > > > > > Now I am working on porting Instant to use Rose::HTML::Form instead of > > > HTML::Wiget - it will give it much more solid base. > > > > > > > I thinking generating the form is a step too far for this sort of > > thing, normally I just want the API. In some cases I'll be generating > > the form HTML with Jemplate for example. > > I think we can still make it compatible, if we agree on some kind of > internal API. >
As in make this module compatible with your new module? Perhaps as a base class without form generation? > > > One more difference in my approach is that the 'update' action will be > > > able to edit not just one row from the DB - but all the interrelated > > > records that together make a full object. This means also adding and > > > removing the related records - so I'll not have the add_to_rel > > > remove_from_rel actions. > > > > > > > Interesting. How are you representing the related objects in the request? > > > > It is I think quite common convention to use '.' dot for that: > > param1.some_relation.field_value > > or > > some_param.some_multi_relation.1.field_value > Makes sense. I prefer that to the add_to_rel action, especially if this is to remain a REST module rather than an RPC module. The piece of functionality I always wanted but didn't see a clean solution to was specifying complex conditions to the 'list' action, for example only CDs which have a track called 'Badgers', which requires specifying a join and a related condition. I wonder if it makes sense to represent that this way too. > > > > > > > > > There is also an effort by Peter Carman: > > > > http://search.cpan.org/~karman/CatalystX-CRUD-0.25/lib/CatalystX/CRUD/REST.pm > > > - and I more or less agreed with Peter on some basics - so that > > > hopefully our code will be compatible and maybe even will form > > > together just one solution. > > > > > > Finally I am waiting for the Moose port of Catalyst - so that all the > > > CRUD functionality could be just a Role instead of forcing the user to > > > 'use base'. > > > > > > > > > > > > > > Note that it lacks: > > > > - list and view type methods which dump objects to JSON (or > whatever) > > > > - clever validation - it should validate based on the DBIC column > > > > definitions but it doesn't > > > > - any auth - not sure if it should or not, but it's possible > > > > > > > > Also it doesn't distinguish between POST, PUT, DELETE and GET HTTP > > > > requests favouring instead entirely separate endpoints, but that's > up > > > > for discussion. > > > > > > > > So, J. Shirley, do you have any interest in a merge? And others, do > > > > you have ideas and would you like to contribute? > > > > > > > > Thanks, > > > > Luke. > > > > > > > > > > > > > > _______________________________________________ > > > > 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/ > > > > > > > > > > > > > > > > -- > > > Zbigniew Lukasiak > > > http://brudnopis.blogspot.com/ > > > > > > _______________________________________________ > > > 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/ > > > > > > > _______________________________________________ > > 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/ > > > > > > -- > Zbigniew Lukasiak > http://brudnopis.blogspot.com/ > > _______________________________________________ > 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/ > _______________________________________________ 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/
