[jifty-devel] Customizing the Jifty Login plugin.
C.G. LEE
yuand2 at gmail.com
Thu Nov 30 23:05:32 EST 2006
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
More information about the jifty-devel
mailing list