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

luke saunders luke.saunders at gmail.com
Sun May 4 12:28:50 BST 2008 

On Sun, May 4, 2008 at 11:58 AM, Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
>
> On Sun, May 4, 2008 at 12:23 PM, luke saunders <luke.saunders at gmail.com> wrote:
>  >
>  > 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.
>
>  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 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/
>  >  >
>  >
>  >  _______________________________________________
>  >  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/
>

More information about the Catalyst mailing list