No subject

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