[jifty-devel] Login plugin questions
jpeacock at rowman.com
Tue Jan 2 13:18:56 EST 2007
Jesse Vincent wrote:
> Would it be possible to make the login plugin's "User" class a mixin
> that requires that the ::Model::$UserClass to implement certain fields?
> I think that might help clean up a lot of the ickiness I run into trying
> to use Login and other plugins at the same time.
I started to make a reply to this from the road, but I lost my network
connection and the web client cookie reset, so I lost what I wrote (the
high tech version of my dog ate it ;).
The short answer is this this would put the cart before the pony(!).
The current architecture requires that any Models live inside the
application's namespace, which means that we can't create tables on
behalf of the application by the plugin. In fact, the current use of
Module::Pluggable means that there must be an actual file containing the
application's Model, even if it is merely a stub inheriting everything
from a plugin.
Ideally, using *any* Plugin should be a matter of adding it to the
SiteConfig.yml file and recreating the database to gain the default
behavior provided by the plugin (we could even create the stub Model
classes if they don't already exist). But I'd be loath to add a scan
for plugin-defined models, since then you'd have to track which ones
already existed, and work out rules if both the app and plugin
implemented. Of course, if you want to add a true mixin environment, we
could have the app extend the plugin model rather than override... hmmm
> Also, what about putting the name of the User class into the config
> file, with a default of ::Model::User? Would that do what you need?
That's actually the current default; as I originally designed it, it is
a little messy (all of the implementation modules have to inherit from
the Login.pm module). In playing around with things, I think I can
simplify it without losing that ability; it would just be cleaner code
if we could state, /a priori/, that the Login plugin requires a table
User containing at least these specified fields.
> IIRC, there's a way to force a different page as the target after the
> login. That might work better.
I haven't figured out how to do that, so I think for now I'll just stick
in a redirect after the logout...
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Lanham, MD 20706
More information about the jifty-devel