[jifty-devel] Login plugin questions

[John Peacock]

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

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