[jifty-devel] Improving our plugin system to make things like ::Login easier

John Peacock jpeacock at rowman.com
Mon Dec 11 10:00:22 EST 2006

Jesse Vincent wrote:
> Using the admin UI...everything just blows up. because among otehr
> things, they end up with a Jifty::Plugin::Login::Model::User as their
> record object, not MyApp::Model::USer

Ah, maybe that's it.  I haven't been trying in the Admin UI, only trying 
to actually use the Login plugin (with the Wifty app).  It may just be 
the way that the admin UI is treating the models.  I'll expand my scope 
when I reinstall my HD's...

>> But how does that inheritance happen in practice?  I'm not sure I see 
>> how this would be any more flexible than the on-the-fly subclassing that 
>>  the Jifty::Plugin::ClassLoader already does.
> ...what we have now is ok for a single plugin touching, say, our user
> model. But it's not at all obvious to me how I'd have two plugins that
> both touched a user model class. 

It's equally non-obvious [to me] how adding an add_parent_class() sub 
would change that (Perl isn't too good with multiple inheritance).

If we want multiple inheritance, perhaps we should go the other way and 
have the base class provide a validate method for *each* field in the 
user database.  Multiple plugins would provide validate methods for each 
of their own fields and the base class would filter only those fields 
which do not have any validation method.  That way, each class can 
extend the schema; the remaining question is whether duplicate field 
methods are LIFO or FIFO (or just punt and say if any method offers to 
validate a given field it should be passed).


John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

More information about the jifty-devel mailing list