FAQ
(Apologies for the repost, I had word-wrap off for the initial one)

Hello all,

I've been watching this project for a long time and have been amazed at the speed
and quality of the development. Many thanks to the people devoting their time to
such a great framework.

I am in the process of porting an app to Catalyst from a simple framework of my own.
I have a number of existing Class::DBI models that I want to reuse and it looked
like C::M::CDBI::Plain was the way to do that:

# FROM THE POD
# use existing CDBI classes within Catalyst:
package MyApp::Model::Artist; # a Catalyst class
use base qw[Catalyst::Model::CDBI::Plain Some::Other::Artist];
1; # That's it

This however, did not work for me at all. Mysterious behavior like updates not
happening, has_a not working, etc. After pulling out my hair and examining/
disabling the CDBI object index I found the cause of the problem. It actually
has to do with the multiple inheritance and Class::Data::Inheritable I believe.

If C::M::CDBI::Plain is in @ISA before Some::Other::Artist, class data from the
existing class (like __grouper) is not seen. This is because
MyApp::Model::Artist->__grouper will be the inherited (and useless)
Class::DBI->__grouper. So I switched to:

use base qw[Some::Other::Artist Catalyst::Model::CDBI::Plain];

Now a test of MyApp::Model::Artist->__grouper does indeed return
Some::Other::Artist->__grouper as desired. But, of course, this is not going to
work inside of Catalyst because MyApp::Model::Artist->new() will be the inherited
and deprecated Class::DBI->new() instead of the C::M::CDBI::Plain->new() that
calls Catalyst::Base->new().

My 5am, coffee-list solution was the rather inelegant:

package MyApp::Model::Artist;
use base qw/ Some::Other::Artist /;
use MyApp::MakeModel;
1;

package MyApp::MakeModel;
use Exporter 'import';
our @EXPORT = qw/ new /;
sub new {
my $class = shift;
$class->Catalyst::Model::new(@_);
}
sub import {
require Catalyst::Model;
my $model_class = caller(0);
push @{"$model_class\::ISA"}, 'Catalyst::Model';
goto &Exporter::import;
}
1;

This works perfectly so far, but is hideous and the inheritance introduced is not
obvious when looking at MyApp::Model::Artist. Ideally I'd just place MakeModel
after the existing model in the "use base" clause. But I don't know a way to get
a "use base"'d class to export a method off the top of my head.

So the questions at the end of all of it are:

Is anyone using C::M::CDBI::Plain?
If not is it deprecated or not-working?
Is there an easier/better way to do this?

I've seen discussion questioning the usefulness of making your models Cat
components, but I want to for cleanliness and to do $c->model('Artist'). I have
started experimenting with a Modelize plugin that takes a list of classes and
turns them into models the same way that MyApp::MakeModel does above. Would that
be a (somewhat) cleaner solution?


Thanks again for such a lively development effort, it's been fun following it.

- Brian Kirkbride

Search Discussions

  • Len Jaffe at Mar 2, 2006 at 6:26 pm
    --- Brian Kirkbride
    wrote:

    I am in the process of porting an app to Catalyst
    from a simple framework of my own.
    I have a number of existing Class::DBI models that I
    want to reuse and it looked
    like C::M::CDBI::Plain was the way to do that:

    # FROM THE POD
    # use existing CDBI classes within
    Catalyst:
    package MyApp::Model::Artist; # a Catalyst
    class
    use base qw[Catalyst::Model::CDBI::Plain
    Some::Other::Artist];
    1; # That's it
    I've trimmed a lot of your post. I won't address
    every bit individually, but I'm also using
    CDBI::plain. I have been unable to get CDBI::plain
    and catalyst to recognize my existing CDBI classes, so
    I have all of my methods in my app::M::CDBI classes.
    I also don't have the code in front of me so I can't
    provide source code now. But I'd like to correspond,
    eiher on list or off, sicne we iconoclasts are a dying
    breed.

    It's kind of a bummer that the catalyst examples are
    all moving to a new ORM, just as I'm finally
    comfortable with CDBI :-) I'm also a little concerned
    abotu finding kwalitee hosting that will have support
    for DBIC, but that's an issue for later when the app
    is finished.

    L.





    Leonard A. Jaffe lenjaffe at jaffesystems.com
    Leonard Jaffe Computer Systems Consulting Ltd.
    Columbus, OH, USA 614-404-4214 F: 530-380-7423
  • Brian Kirkbride at Mar 2, 2006 at 10:41 pm

    Len Jaffe wrote:
    I've trimmed a lot of your post. I won't address
    every bit individually, but I'm also using
    CDBI::plain. I have been unable to get CDBI::plain
    and catalyst to recognize my existing CDBI classes, so
    I have all of my methods in my app::M::CDBI classes.
    I also don't have the code in front of me so I can't
    provide source code now. But I'd like to correspond,
    eiher on list or off, sicne we iconoclasts are a dying
    breed.

    It's kind of a bummer that the catalyst examples are
    all moving to a new ORM, just as I'm finally
    comfortable with CDBI :-) I'm also a little concerned
    abotu finding kwalitee hosting that will have support
    for DBIC, but that's an issue for later when the app
    is finished.

    L.
    I agree, I'll probably move to DBIC after the app is up and running. That's
    the great thing about MVC, right? :)

    In the meantime, the solution does seem to require that Catalyst::Model come
    after other base classes in @ISA. But new() must be Catalyst::Component->new()
    and COMPONENT() must be Catalyst::Component->COMPONENT.

    I've attached a fairly straightforward solution to the problem. It's a new
    model class Catalyst::Model::Existing. It provides a completely generic
    and safe way to integrate existing model classes into Catalyst without the
    headache I just went through.

    Comments/criticism?

    - Brian
    -------------- next part --------------
    An embedded and charset-unspecified text was scrubbed...
    Name: Catalyst_Model_Existing.pm
    Url: http://lists.rawmode.org/pipermail/catalyst/attachments/20060302/465ece9b/attachment-0001.diff
  • Sebastian Riedel at Mar 3, 2006 at 6:02 am

    02.03.2006 19:26 Len Jaffe:
    It's kind of a bummer that the catalyst examples are
    all moving to a new ORM, just as I'm finally
    comfortable with CDBI :-) I'm also a little concerned
    abotu finding kwalitee hosting that will have support
    for DBIC, but that's an issue for later when the app
    is finished.
    "kwalitee hosting" for Catalyst would at least provide Task::Catalyst
    (and keep it updated).


    --
    sebastian
  • Simon Wilcox at Mar 3, 2006 at 8:13 am

    On Fri, 3 Mar 2006, Sebastian Riedel wrote:

    "kwalitee hosting" for Catalyst would at least provide Task::Catalyst
    (and keep it updated).
    Given the speed of change, the inconsistency of interfaces between
    different versions and the high likelihood of app breakage I would argue
    that a "kwalitee" host for Catalyst would do no such thing.

    I would suggest a FastCGI environment with a custom perl for each user
    that has local lib paths to the users' home directory so that they can
    more easily control their non-core packages without trampling all over
    the other users of the machine.

    There are probably loads of problems with this approach but I am a bit
    caffeine light this morning :-)

    Simon.
  • Aristotle Pagaltzis at Mar 3, 2006 at 9:09 am
    * Simon Wilcox [2006-03-03 09:20]:
    I would suggest a FastCGI environment with a custom perl for
    each user that has local lib paths to the users' home directory
    so that they can more easily control their non-core packages
    without trampling all over the other users of the machine.
    This is the kind of thing for which the ?relocatable perl? work
    that is part of the deliverables of Nick Clark?s recent TPF grant
    will probably be of particular value?

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Thomas Hartman at Mar 3, 2006 at 6:50 pm
    Dreamhost has this -- don't they?

    2006/3/3, Simon Wilcox <simonw at digitalcraftsmen.net>:
    I would suggest a FastCGI environment with a custom perl for each user
    that has local lib paths to the users' home directory so that they can
    more easily control their non-core packages without trampling all over
    the other users of the machine.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedMar 2, '06 at 5:56p
activeMar 3, '06 at 6:50p
posts7
users6
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase