On 6/19/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Unfortunately there is (yet) no Catalyst::Model::IMAP available, so I
> considered --most audaciously-- to start writing such a model myself. I had
> a look at various models (such as DBIC) but could not easily re-engineer
> the rules I must follow to write such a model-class.
>
> I did find the "Writing plug-ins" tutorial and wonder whether a "Model is
> just a kind of "Plugin" with another name. If not, is there somewhere a
> handy guide to start writing Models? I do agree to keep a log of my
> wanderings on the path of writing a Model and make it available once the
> Catalyst::Model::IMAP is finished.
>
The basic idea is this: a model class should "use base" on
Catalyst::Model, which in turn uses the base class
Catalyst::Component. Catalyst::Component's source code is a
must-read. It defines basic implementations of "new", "config", and
"COMPONENT" (ignore "process" for models).
If your new C::M::IMAP declares nothing else and just inherits the
defaults, a user will be able to "use base Catalyst::Model::IMAP" in
their own "MyApp::Model::FooBar", and set ->config entries for it, and
get a reasonable object returned to them when they call
$c->model('FooBar')
This "reasonable object" is basically an object of class
"MyApp::Model::FooBar" whose object data consists of whatever config
values were supplied (__PACKAGE__->config() in the model class itself,
and/or config->{'MyApp::Model::FooBar'}->.... in the main app config,
etc).
>From there you could give the object further methods by defining them
in C::M::IMAP, you could override "new" to do some initialization
activities based on the $config and/or store more object data than was
provided in $config, etc.
COMPONENT and ACCEPT_CONTEXT are a little more advanced. By
overriding these methods, you can have your model object actually
return other things than itself when called via $c->model('FooBar').
COMPONENT happens at component init time, ACCEPT_CONTEXT happens at
actual call time.
If you look at C::M::DBIC::Schema as an example, you'll see that there
really is a model object being created, which ISA Catalyst::Component,
and contains as one of its data members a DBIx::Class::Schema object.
However, it uses ACCEPT_CONTEXT to set things up so that
$c->model('ModelName::TableName') returns a specific DBIC resultset
object, for example.
It would probably be best to include as little LDAP-specific code in
your model, and much like M::DBIC::Schema, focus on being just a layer
of adaptation. non-Cat-specific LDAP code can be put in a seperate
module that your Model makes use of. (And the model should probably
be named for the name of the LDAP module(s) it uses, as their might be
more than one implementation down the road).
-- Brandon
_______________________________________________
List: [email protected]
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
