[Catalyst] Re: [RHTMLO] RDBO/RHTMLO integration with Catalyst - work in progress

[Peter Karman]

Matt S Trout wrote on 7/22/07 12:48 PM:
> On Sat, Jul 21, 2007 at 08:02:24AM -0500, Peter Karman wrote:
>> check out Catalyst::Controller::Rose on cpan.
>>
>> It has a different philosophy than what you've described. But if you find 
>> features missing that you think would make it more useful, please send me 
>> patches/tests/docs etc. You might consider writing a new 
>> Catalyst::Controller::Rose::SomeThing to implement what you're describing 
>> with YAML.
> 
> Do you have any plans to split the dependencies a bit on this?
> 

I hadn't any plans, but since you've raised the issue, I'd be happy to discuss it.

> I've always been quite fond of RHTMLO and have been on a couple projects now
> where we considered Controller::Rose and had to pass on it because it
> assumed you wanted RDBO as well.

C::C::Rose assumes that you are going to override methods in your subclasses, so 
it should be able to work with just about any model, I would think.

All that is required is that the model class returned by model_name() implement 
the same methods as C::M::RDBO. C::M::RDBO is intentionally agnostic w.r.t. 
method names. I.e., it doesn't use the same method names as RDBO or RDBO::Manager.

So a model needs to implement:

  * create()   - make an object (i.e. MyObject->new())
  * fetch()    - load an object's data
  * search()   - return an arrayref of objects
  * count()    - return a count of matches
  * iterator() - return an iterator instead of arrayref of objects

fetch_all() and all() are just aliased to search() right now.

C::C::Rose::CRUD just needs fetch() and create() to work, and for the returned 
object to implement a save() and delete() method. Even save() is optional -- 
just override save_obj() and make the object do whatever you want.

C::C::Rose::Search is a little trickier since rose_query() and setup() assume 
RDBO::QueryBuilder is the target SQL generator. But again, those can be 
overridden to adapt to whatever your model's search() method can accept.

So if (for example) you wanted to use DBIC with C::C::Rose, you'd need a model 
that implements the methods above. But grok C::M::RDBO -- with the execption of 
fetch(), there's really not much going on in there. I wouldn't think it would be 
hard to write a DBIC-compatible model than implements the C::M::RDBO API.

How do you imagine C::C::R::CRUD and ::Search could play friendlier with other 
models?


> 
> Catalyst stuff should really be as non-opinionated as possible - people might
> want to use RDBO with a different form library too, and it'd be nice for the
> glue to elegantly support that case as well.
> 

Hm. Catalyst stuff should be non-opinionated, but I don't see how one Controller 
can be all things to all users. C::C::Rose assumes RHTMLO but can be flexible 
with the Model. And you can use C::M::RDBO with any kind of controllers you want.

But if folks wanted to use a different form library with C::M::RDBO, and their 
form library doesn't have an API remotely close to RHTMLO's, then they should 
probably be using a different package. We don't ask 
Catalyst::Controller::FormBuilder to support RHTMLO do we? ;)



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