[Catalyst] Instant CRUD with DBIC::Schema

[Zbigniew Lukasiak]

After some more playing with CatalystX::CRUD I think I can formulate
my arguments a bit more clearly.

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.


--
Zbigniew

On Mon, Mar 10, 2008 at 3:53 PM, Peter Karman <peter at peknet.com> wrote:
>
>
>  On 03/10/2008 07:14 AM, Zbigniew Lukasiak wrote:
>  > Hi Peter,
>  >
>  > On Wed, Feb 20, 2008 at 7:48 PM, Peter Karman <peter at peknet.com> wrote:
>  >>  Also look at CatalystX::CRUD::Model::DBIC. Feedback appreciated.
>  >>
>  >
>  > I had today another look at CatalystX::CRUD - it is promising, but I
>  > think there is too many indirection layers in it.
>
>  I usually fault the other direction, so that's an interesting read.
>
>
>  For DBIC it
>  > requires configuration of both CatalystX::CRUD::Model::DBIC and
>  > CatalystX::CRUD::Object::DBIC.  I believe it could work with just one
>  > - for example CatalystX::CRUD::Model::DBIC where you could configure
>  > what methods on the object and how to call them to implement the
>  > needed interface.
>  >
>  > Or perhaps you could all of it move to CatalystX::CRUD::Model and add
>  > configuration to interface it to DBIC and RDBO - they are not that
>  > different.
>  >
>  > What do you think?  I believe some reduction of the number of modules
>  > used will simplify the whole thing.
>
>  :) could be said for Catalyst in general...
>
>
>  > Maybe we could start the
>  > discussion with what you interface you need from the database model?
>  >
>
>  My assumptions are:
>
>  1. CRUD is not just databases. I have a CatalystX::CRUD::Model::SVN and CatalystX::CRUD::Model::File
>  (the latter as part of the core CX::CRUD dist). I'm also going to be working on a ::LDAP
>  implementation, which is a database but not a SQL-based ORM type one.
>
>  2. The Model class interacts with many Objects. The Model searches and fetches, returning array or
>  iterator or count. The Object is singular. It creates/reads/updates/deletes one item (a db row, a
>  file, etc). I know that the DBIC ResultSet combines some of those features into one class, allowing
>  you to update/delete/etc multiple rows at a time. I find that less simple, conceptually, even if it
>  is more convenient to use. Simple is not always the same as convenient, in my book. Or otoh, a
>  simple user interface might well be convenient to the user, but a real pita (i.e. not simple) to the
>  developer who must implement it.
>
>  3. Users of a CX::CRUD::Model::* should not, in the common case, need to override or configure the
>  ::Object class. It's there to implement the basic create/read/update/delete methods for the
>  Model-specific object. But it should be, for all practical purposes, invisible to the user. That's
>  why there is evil AUTOLOAD hackery in the base Model.
>
>  For a ORM like RDBO or DBIC, the Object class consists of easy pass-throughs to the appropriate
>  method on the delegate() object. But check out CatalystX::CRUD::Object::File for
>  one case where it is not so simple.
>
>  If you need to override the behaviour of the ::Object class for any given CX::CRUD::Model,
>  especially for an ORM, I suspect that it should really be overridden outside of Catalyst altogether,
>  in the delegate class. These are "thin" Models.
>
>  I do like the idea of simplifying. What I hear you saying is that getting rid of the Object class
>  would simplify things. I don't think it would. I think it would require mixing 2 different concepts
>  (the thing that gets objects, and the object itself). I tried to keep the API as high-level and
>  simple as I could. Individual implementations (like that for RDBO and DBIC) can get more complicated
>  because they have to implement an API that isn't necessarily like their own. I think of it like DBI
>  and the various DBD drivers.
>
>  That said, if you have specific changes you'd like to see, I'm open to persuasion. I'm just not
>  persuaded yet. :)
>
>
>
>  --
>  Peter Karman  .  peter at peknet.com  .  http://peknet.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/
>



-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/