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
_______________________________________________
jifty-devel mailing list
[email protected]
http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel
