[jifty-devel] Customizing the Jifty Login plugin.

[C.G. LEE]

Thanks guys,

I've got what I wanted. It looks ugly and instant but I've never  touched
the Jifty Core and Login plugin. I failed sending a confirm email, howerver,
the user infomation was saved successfully.

I don't know well about  the Module::Pluggable module. I just thought
there's a problem in Jifty actions in a request because when I depulicate a
moniker in two actions, the $action, which is in the signup template as an
mason argument, showed different identity; some times undefined, and some
times as a Jifty::Plugin::Login::Action::Singup or App::Action::Singup. So,
to freeze up the $action in my flavor, and I thought the template is the
very key to solve these messy ploblems at once.

Anyway... this is my recipe.


First, copy the Login's Dispacher.pm and paste it onto the App::
Dispatcher.pm and modify the package name.

Second, add the below in the app's Dispatcher:

# Sign up for an account
before 'signup' => run {
    #redirect('/');
    #Jifty->api->deny( qr'signup' );
    Jifty->api->reset;
};

Next, copy and paste the Login's Signup action to App::Action::Signup.pm,
and modify the package name.

And the last, apply the recent patch if you've not yet
patched(Login::Action::Signup.pm) OR just edit the app's Signup.pm. Find the
arguments() and comment out the line as below:

sub arguments {
    ...
    #for ( keys %$args ) { delete $args->{$_} unless ( $fields{$_} ); }
    ...
}


And the following is my User.pm:

use strict;
use warnings;

package TestApp::Model::User::Schema;
use Jifty::DBI::Schema;
use TestApp::Model::Group;

column name =>
    type is 'text',
    label is 'Name',
    render_as 'Text',
    since '0.0.10',
    is mandatory;

column email =>
    type is 'text',
    label is 'Email address',
    render_as 'Text',
    is mandatory,
    since '0.0.10',
    is distinct;

column password =>
    type is 'text',
    label is 'Password',
    is mandatory,
    since '0.0.10',
    render_as 'password';

column email_confirmed =>
    label is 'Email address confirmed?',
    since '0.0.10',
    type is 'boolean';

column auth_token =>
    type is 'text',
    since '0.0.10',
    render_as 'Password';

column homepage =>
    type is 'text',
    label is 'Homepage',
    since '0.0.10',
    render_as 'Text';

column blog =>
    type is 'text',
    label is 'Blog address',
    since '0.0.10',
    render_as 'Text';

column interest =>
    type is 'text',
    label is 'Your interests',
    since '0.0.10',
    render_as 'Textarea';

column wannasay =>
    type is 'text',
    label is 'What you want to say',
    since '0.0.10',
    render_as 'Textarea';

column grp =>
    refers_to TestApp::Model::Group,
    since '0.0.10';


package TestApp::Model::User;
use base qw/Jifty::Plugin::Login::Model::User/;
#use base qw/TestApp::Record/;

# Your model-specific methods go here.

1;




On 11/30/06, John Peacock <jpeacock at rowman.com> wrote:
>
> Wolfgang Kinkeldei wrote:
> >> Error in /home/w3pm/perl/lib/site_perl/5.8.8/Jifty/Action/Record.pm
> >> line 149 Can't locate object method "homepage" via package
> >> "Jifty::Plugin::Login::Model::User"
> >> I think Jifty grabs my User(Model) but not my Signup(Action). I could
> >> edit the Login dispatcher, but I don't want to touch the Login. Please
> >> show me the recipe if you have.
>
> There are a couple of things going on behind the scenes that are not
> immediately
> evident.  If you just add the Login plugin to an application (and don't
> override
> anything), Jifty::Plugin->new() creates virtual classes in the application
> namespace that are wrappers of the Jifty::Plugin classes, inheriting all
> of
> their methods using the normal Perl inheritance model.
>
> However, if you override the Jifty::Plugin classes with your own, those
> classes
> take over, so it should be possible to extend the base classes.  But
> somewhere
> in the interaction with Module::Pluggable, the inheritance is breaking
> down and
> I have not been able to figure out where.
>
> > I tested a bit to see what happens. If you create a class
> > "App::Model::User" having "Jifty::Plugin::Login::Model::User" as base
> > and append fields to the schema, the database is created right. fine.
>
> This shows that the inherited classes are correctly being called here.
>
> > After an action of class "App::Action::CreateUser" is build via
> > Jifty->web->new_action, this action reports its "record_class" to be
> > "Jifty::Plugin::Login::Model::User" instead of your own class
> > "App::Model::User".
>
> This is where things go wrong.  I /think/ that the problem is that the
> schema
> class is working (so the database gets the write table structure), but
> that the
> implementation class is still inheriting the base class.  I just can't
> track
> down where that is happening.  So much is happening on the fly as the app
> executes that it is very tricky to figure out where things are happening.
>
> > I am not quite sure, but I think this is a
> > side-effect of Module::Pluggable, as I did never see a
> > "App::Action::CreateUser" to get created by "Jifty::ClassLoader".
>
> There will actually be three (in the single plugin case) "ClassLoader"
> entries
> in @INC:
>
> 1) the one providing the application classes/methods;
> 2) the one providing access the Login plugin classes/methods;
> 3) the one providing access to the base Jifty classes/methods.
>
> Those are listed, in that order, in @INC, so the normal inheritance walk
> finds
> the first existing class that implements that object.  The part that makes
> that
> tricky is that both #2 and #3 are created on the fly (meaning they aren't
> there
> until they need to be).  This is the Module::Pluggable piece that makes
> things
> so difficult to debug.
>
> > However, the Action modules in the Login plugin explicitly use the
> > "Jifty::Plugin::Login::Action::..." actions, so they will not work on
> > expanded models.
>
> No, the inherited class (whether implied or explicit) should be calling
> them as
> App::Action::.. and the Perl inheritance rules will dispatch the actual
> method
> with the App object as $self.
>
> I just checked in a very small patch that deals with a different
> limitation of
> the Login plugin: Login::Action::Signup would delete unknown args that
> were
> submitted, but it only "knew" about the fields which were in the default
> class
> (so it would nuke extended attributes).  I've deleted this and also made
> the
> email_confirmed and auth_token fields "Unrendered", which has almost
> exactly the
> same effect.  We should still have a way for an inherited class to
> validate the
> submitted args (to prevent form injection hacks).
>
> John
>
> --
> John Peacock
> Director of Information Research and Technology
> Rowman & Littlefield Publishing Group
> 4501 Forbes Blvd
> Suite H
> Lanham, MD 20706
> 301-459-3366 x.5010
> fax 301-429-5747
> _______________________________________________
> jifty-devel mailing list
> jifty-devel at lists.jifty.org
> http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.bestpractical.com/pipermail/jifty-devel/attachments/20061130/a2e36c6b/attachment.htm