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. > 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? > 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/