[Catalyst] Instant CRUD with DBIC::Schema

[Zbigniew Lukasiak]

On Wed, Mar 12, 2008 at 12:33 PM, Kieren Diment <diment at gmail.com> 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.

Yeah - I hope there is a room for two competitors here.

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

Just thinking how this can be done - you need a
CatalystX::CRUD::ModelAdaptor::XXXX and a model_adaptor_class config
option for the CRUD controller.  Then in the controller methods you
would do:

$c->stash->{object} = $self->model_adaptor->fetch( @arg );

instead of

$c->stash->{object} = $c->model( $self->model_name )->fetch(@arg);

and in places where you call methods on the object like: $obj->$method
you could do again $self->model_adaptor->$method( $obj ).

This way $c->stash->{object} could still be an unmodified object from
the model and you would have your indirection layer needed to make the
CRUD methods universal.

Cheers
Zbigniew




>  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).
>
>
>
>
>  _______________________________________________
>  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/