[jifty-devel] Better plugin models

[Andrew Sterling Hanenkamp]

Just wanted to let everyone know that I've committed a change to the way
models in plugins should work. As far as Jifty proper is concerned, this
only effects the OAuth plugin and possibly some of the deprecated login
plugins. With a patch I made a month or two ago, models are now able to have
models properly (before that they could only implement a base class that
could be implemented in the app or provide mixins implemented in an app
model).

To make this go, you just do the obvious:

package Jifty::Plugin::MyPlugin::Model::MyModel;
use Jifty::DBI::Schema;
use Jifty::Record schema {
    column my_column => type is 'text';
};

You can then use the model via:

my $o = Jifty::Plugin::MyPlugin::Model::MyModel->new;
# etc.

However, my new patch changes the preferred mechanism to:

my $o = MyApp::Model::MyModel->new;
# etc.

Or from the plugin:

my $o = Jifty->app_class('Model', 'MyModel')->new;
# etc.

The reason for this change is three-fold.

(1) If you use a model in the plugin namespace you have some trouble doing
things like referencing other application models, especially User. This
implementation should avoid these issues.

(2) Sometimes mixins aren't really what you want in a plugin. You just want
to provide a model that the application might choose to extend. In such
cases, a mixin just ends up being a bit of extra work and does not imply
that you, the plugin author, want just one specific model in the
application.

(3) The application may now explicitly override the plugin model to provide
additional columns or methods, but doesn't have to because the class loader
makes it magically work if you don't.

(4) This makes model handling consistent with the way that actions and
notifications are already handled to allow the application the ability to
customize the plugin.

Finally, this doesn't (shouldn't) break anything because you can still use
the models from the plugin side of things as it has been already. If you use
the plugin model directly, the table has the plugin namespace prefix
inserted in front (unless you override table() as OAuth does). If you use
the app model that subclasses the plugin mode, the table acts like a regular
table in the application. This does have the same potential for a namespace
clash that plugin actions and notifications have, so be careful about naming
plugin models.

So ends my dissertation on plugin models.

Cheers,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.bestpractical.com/pipermail/jifty-devel/attachments/20071130/dc3cb248/attachment.htm