[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
--
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