Thanks guys,<br><br>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. <br><br>
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.
<br><br>Anyway... this is my recipe.<br><br><br>First, copy the Login's <a href="http://Dispacher.pm">Dispacher.pm</a> and paste it onto the App::<a href="http://Dispatcher.pm">Dispatcher.pm</a> and modify the package name.
<br><br>Second, add the below in the app's Dispatcher:<br><br># Sign up for an account<br>before 'signup' => run {<br> #redirect('/');<br> #Jifty->api->deny( qr'signup' );<br> Jifty->api->reset;
<br>};<br><br>Next, copy and paste the Login's Signup action to App::Action::<a href="http://Signup.pm">Signup.pm</a>, and modify the package name.<br><br>And the last, apply the recent patch if you've not yet patched(Login::Action::
<a href="http://Signup.pm">Signup.pm</a>) OR just edit the app's <a href="http://Signup.pm">Signup.pm</a>. Find the arguments() and comment out the line as below:<br><br>sub arguments {<br> ...<br> #for ( keys %$args ) { delete $args->{$_} unless ( $fields{$_} ); }
<br> ...<br>}<br><br><br>And the following is my <a href="http://User.pm">User.pm</a>:<br><br>use strict;<br>use warnings;<br><br>package TestApp::Model::User::Schema;<br>use Jifty::DBI::Schema;<br>use TestApp::Model::Group;
<br><br>column name => <br> type is 'text',<br> label is 'Name',<br> render_as 'Text',<br> since '0.0.10',<br> is mandatory;<br><br>column email => <br> type is 'text',<br> label is 'Email address',
<br> render_as 'Text',<br> is mandatory,<br> since '0.0.10',<br> is distinct;<br><br>column password =><br> type is 'text',<br> label is 'Password',<br> is mandatory,<br> since '0.0.10',<br> render_as 'password';
<br><br>column email_confirmed => <br> label is 'Email address confirmed?',<br> since '0.0.10',<br> type is 'boolean';<br><br>column auth_token => <br> type is 'text',<br> since '0.0.10',<br> render_as 'Password';
<br><br>column homepage =><br> type is 'text',<br> label is 'Homepage',<br> since '0.0.10',<br> render_as 'Text';<br><br>column blog =><br> type is 'text',<br> label is 'Blog address',<br> since '
0.0.10',<br> render_as 'Text';<br><br>column interest =><br> type is 'text',<br> label is 'Your interests',<br> since '0.0.10',<br> render_as 'Textarea';<br><br>column wannasay =><br> type is 'text',
<br> label is 'What you want to say',<br> since '0.0.10',<br> render_as 'Textarea';<br><br>column grp =><br> refers_to TestApp::Model::Group,<br> since '0.0.10';<br><br><br>package TestApp::Model::User;<br>
use base qw/Jifty::Plugin::Login::Model::User/;<br>#use base qw/TestApp::Record/; <br><br># Your model-specific methods go here.<br><br>1;<br><br><br><br><br><div><span class="gmail_quote">On 11/30/06, <b class="gmail_sendername">
John Peacock</b> <<a href="mailto:jpeacock@rowman.com">jpeacock@rowman.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Wolfgang Kinkeldei wrote:<br>>> Error in /home/w3pm/perl/lib/site_perl/5.8.8/Jifty/Action/Record.pm<br>>> line 149 Can't locate object method "homepage" via package<br>>> "Jifty::Plugin::Login::Model::User"
<br>>> I think Jifty grabs my User(Model) but not my Signup(Action). I could<br>>> edit the Login dispatcher, but I don't want to touch the Login. Please<br>>> show me the recipe if you have.<br><br>There are a couple of things going on behind the scenes that are not immediately
<br>evident. If you just add the Login plugin to an application (and don't override<br>anything), Jifty::Plugin->new() creates virtual classes in the application<br>namespace that are wrappers of the Jifty::Plugin classes, inheriting all of
<br>their methods using the normal Perl inheritance model.<br><br>However, if you override the Jifty::Plugin classes with your own, those classes<br>take over, so it should be possible to extend the base classes. But somewhere
<br>in the interaction with Module::Pluggable, the inheritance is breaking down and<br>I have not been able to figure out where.<br><br>> I tested a bit to see what happens. If you create a class<br>> "App::Model::User" having "Jifty::Plugin::Login::Model::User" as base
<br>> and append fields to the schema, the database is created right. fine.<br><br>This shows that the inherited classes are correctly being called here.<br><br>> After an action of class "App::Action::CreateUser" is build via
<br>> Jifty->web->new_action, this action reports its "record_class" to be<br>> "Jifty::Plugin::Login::Model::User" instead of your own class<br>> "App::Model::User".<br><br>This is where things go wrong. I /think/ that the problem is that the schema
<br>class is working (so the database gets the write table structure), but that the<br>implementation class is still inheriting the base class. I just can't track<br>down where that is happening. So much is happening on the fly as the app
<br>executes that it is very tricky to figure out where things are happening.<br><br>> I am not quite sure, but I think this is a<br>> side-effect of Module::Pluggable, as I did never see a<br>> "App::Action::CreateUser" to get created by "Jifty::ClassLoader".
<br><br>There will actually be three (in the single plugin case) "ClassLoader" entries<br>in @INC:<br><br>1) the one providing the application classes/methods;<br>2) the one providing access the Login plugin classes/methods;
<br>3) the one providing access to the base Jifty classes/methods.<br><br>Those are listed, in that order, in @INC, so the normal inheritance walk finds<br>the first existing class that implements that object. The part that makes that
<br>tricky is that both #2 and #3 are created on the fly (meaning they aren't there<br>until they need to be). This is the Module::Pluggable piece that makes things<br>so difficult to debug.<br><br>> However, the Action modules in the Login plugin explicitly use the
<br>> "Jifty::Plugin::Login::Action::..." actions, so they will not work on<br>> expanded models.<br><br>No, the inherited class (whether implied or explicit) should be calling them as<br>App::Action::.. and the Perl inheritance rules will dispatch the actual method
<br>with the App object as $self.<br><br>I just checked in a very small patch that deals with a different limitation of<br>the Login plugin: Login::Action::Signup would delete unknown args that were<br>submitted, but it only "knew" about the fields which were in the default class
<br>(so it would nuke extended attributes). I've deleted this and also made the<br>email_confirmed and auth_token fields "Unrendered", which has almost exactly the<br>same effect. We should still have a way for an inherited class to validate the
<br>submitted args (to prevent form injection hacks).<br><br>John<br><br>--<br>John Peacock<br>Director of Information Research and Technology<br>Rowman & Littlefield Publishing Group<br>4501 Forbes Blvd<br>Suite H<br>
Lanham, MD 20706<br>301-459-3366 x.5010<br>fax 301-429-5747<br>_______________________________________________<br>jifty-devel mailing list<br><a href="mailto:jifty-devel@lists.jifty.org">jifty-devel@lists.jifty.org</a><br>
<a href="http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel">http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel</a><br></blockquote></div><br>