Jesse, We've discussed it before and I believe it was your intention that plugins be able to supply their own models. Up to this point, it has not been possible. I have created a patch that will make it possible, but I've not committed it yet. I wanted to run it by you first to make sure I haven't stepped in anything.
You can find the patch attached. It includes modifications to Jifty::Plugin, Jifty::Schema, and Jifty::Script::Schema along with a new test application and a single test that verifies the basics. (I'm planning a couple more to make sure that plugin models cooperate properly with app models and that upgrades work.) Anyway, the major fix is in two areas: 1. Jifty::Schema now includes any models found under installed plugins and adds them to Jifty->schema->models 2. Jifty::Script::Schema now iterates through installed plugins when checking for installation and upgrades. Supporting the later piece, I have added some new methods to Jifty::Plugin that are inherited with the expected defaults: - $plugin->version: Returns the database version of the plugin. Returns 0.0.1 unless overridden. - $plugin->bootstrapper: Returns the bootstrap class for the plugin. Returns $plugin_class::Bootstrap unless overidden. - $plugin->upgrade_class: Returns the bootstrap class for the plugin. Returns $plugin_class::Upgrade unless overridden. That's it. Thanks to Jesse and Alex, et. al. this patch was pretty simple. Oh, there is one possible nasty you may run into (at least I did). I had installed an old version of Jifty at some point where Authentication::Password and the User plugins had User models. This caused bad things to happen. I also wonder if each plugin might want to supply a prefix to the table names to avoid collisions. Cheers, Andrew
plugin-models.patch
Description: Binary data
_______________________________________________ jifty-devel mailing list [email protected] http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel
