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). 
<br><br>To make this go, you just do the obvious:<br><br>package Jifty::Plugin::MyPlugin::Model::MyModel;<br>use Jifty::DBI::Schema;<br>use Jifty::Record schema {<br>&nbsp;&nbsp;&nbsp; column my_column =&gt; type is &#39;text&#39;;<br>};
<br><br>You can then use the model via:<br><br>my $o = Jifty::Plugin::MyPlugin::Model::MyModel-&gt;new;<br># etc.<br><br>However, my new patch changes the preferred mechanism to:<br><br>my $o = MyApp::Model::MyModel-&gt;new;
<br># etc.<br><br>Or from the plugin:<br><br>my $o = Jifty-&gt;app_class(&#39;Model&#39;, &#39;MyModel&#39;)-&gt;new;<br># etc.<br><br>The reason for this change is three-fold. <br><br>(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.
<br><br>(2) Sometimes mixins aren&#39;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.
<br><br>(3) The application may now explicitly override the plugin model to provide additional columns or methods, but doesn&#39;t have to because the class loader makes it magically work if you don&#39;t.<br><br>(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.
<br><br>Finally, this doesn&#39;t (shouldn&#39;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.
<br><br>So ends my dissertation on plugin models.<br><br>Cheers,<br>Andrew<br>