[Catalyst] RFC: Catalyst::Controller::REST::DBIC

[luke saunders]

On Sun, May 4, 2008 at 10:20 AM, Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
>
> On Sun, May 4, 2008 at 2:38 AM, luke saunders <luke.saunders at gmail.com> 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 at 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 at 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/
>