[Catalyst] Instant CRUD with DBIC::Schema

[Peter Karman]

On 03/12/2008 06:33 AM, Kieren Diment wrote:
> 
> On 12 Mar 2008, at 21:50, Zbigniew Lukasiak wrote:
> 
>> After some more playing with CatalystX::CRUD I think I can formulate
>> my arguments a bit more clearly.
>>
> 
> OK, bear in mind that you're competing with Reaction here.  Reaction has
> some promise, but its development is slow so far (for casual users
> anyway), and it may suffer from some of the hyperverbosity  and/or
> (superficially) excessive indirection that is endemic in enterprise
> ready™ software. I'm not qualified to comment further on this.
> 

I didn't get the sense that CX::CRUD is competing with Reaction. CX::CRUD is, as mst put
it, a simple solution for a simple problem. Reaction seems to have loftier goals.

By "simple" I mean it is supposed to be simple for the user. Subclass
CX::CRUD::Controller::RHTMLO and you've adapted your existing RHTMLO form to Catalyst. The
idea is the same as for jrockway's Model adapter.

Authors of CX::CRUD Models and Controllers (like zby is attempting with DBIC and FormFu)
may find it not so simple. Then it's up to us to hash out whether that is the fault of the
documentation or the API or the design. Or some combination of those.

> 
>> I believe the objects that users of CatalystX::CRUD get in their
>> controller should be the real things - i.e. objects from their models
>> not CatalystX::CRUD::Model::Objects.  This would be the  minimal
>> interface and minimal hassle for injecting CatalystX::CRUD::Controller
>> actions to a legacy Catalyst controller.
>>
> 
> What I particularly like about InstantCRUD is that everything is spelled
> out nicely for the coder once they run the helper.  That is, mostly once
> you've been through the catalyst learning curve, the instantcrud
> learning curve isn't very much more at all.  InstantCRUD's main problem
> is HTML::Widget, and secondarily the lack of many-to-many
> introspection.  I'm not sure how big the problem with the tight coupling
> with DBIC is - I'd like to see a shitfight between merlyn and mst, with
> zby as mediator to straighten that one out.  Or maybe between merlyn and
> zby with mst mediating ...
> 
> I think it would be best  to be able to treat a CatalystX::CRUD
> application like any other catalyst application.  That is, minimal
> modification of $c->model('Foo') compared to an ordinary catalyst app so
> that the CRUD generator mostly gets out of the way.

Clarification: CX::CRUD is *not* a code generator. It is not like InstantCRUD in that
sense. Or really in any sense. CX::CRUD is first an API and second a collection of base
classes to make implementing that API easier for specific packages. That is, I never use
CX::CRUD in my Catalyst apps. I use CX::CRUD::Controller::RHTMLO and CX::CRUD::Model::RDBO
quite a lot. So does Rose::DBx::Garden::Catalyst, with which you might be confusing CX::CRUD.


> 
> For bonus points I'd like to see a REST service available by default,
> with a browser based service available on top of this.  This way we get
> the API for free and the browser UI  gets to forward to the REST API
> (with suitable massaging of the stash).

CX::CRUD::REST is part of the core dist. It is designed to make swapping between REST and
RPC-style APIs as trivial as:

 use base qw( CatalystX::CRUD::REST CatalystX::CRUD::Controller::SomeThing );

where SomeThing is currently RHTMLO or (hopefully soon) FormFu.

-- 
Peter Karman  .  peter at peknet.com  .  http://peknet.com/