Rails - Jun 2005 - Confused about login controller in Agile beta book

Looking at "print page 123" (PDF page 133) of beta 2, we see the login
action from the login controller:

def login
  if request.get?
    session[:user_id] = nil
    @user = User.new
  else
    @user = User.new(params[:user])
    logged_in_user = @user.try_to_login
    if logged_in_user
      session[:user_id] = logged_in_user.id
      redirect_to(:action => "index")
    else
      flash[:notice] = "Invalid user/password combination"
    end
  end
end

and in the user model:

def self.login(name, password)
  hashed_password = hash_password(password || "")
  find(:first,
       :conditions => ["name = ? and hashed_password = ?",
       name, hashed_password])
  end

def try_to_login
  User.login(self.name, self.password)
end

So the login action instantiates a new User object, with the correct 
user name.  It then calls the try_to_login instance method, which calls 
the login class method.

Why do we need this trickery?  The book calls the code 
"straightforward", but as a Ruby (and OOP) newbie, it''s not. 
Why can''t
the login action call User.login directly? 

-- 
Jay Levitt                | 
Wellesley, MA             | I feel calm.  I feel ready.  I can only
Faster: jay at jay dot fm | conclude that''s because I don''t
have a
http://www.jay.fm         | full grasp of the situation. - Mark Adler

You can. The reason why he did this is so that he can use the
User.new(params[:user]) feature of active record. Another way to do
the same thing is to use User.login(params[:user][:login],
params[:user][:password])  but make sure to test if params[:user] is
nil because in this case trying to access params[:user][:login] will
obviously give you an error about calling [:login] on a nil object.


On 6/26/05, Jay Levitt <jay-news-WxwZQdyI2t0@public.gmane.org>
wrote:
> Looking at "print page 123" (PDF page 133) of beta 2, we see the
login
> action from the login controller:
> 
> def login
>   if request.get?
>     session[:user_id] = nil
>     @user = User.new
>   else
>     @user = User.new(params[:user])
>     logged_in_user = @user.try_to_login
>     if logged_in_user
>       session[:user_id] = logged_in_user.id
>       redirect_to(:action => "index")
>     else
>       flash[:notice] = "Invalid user/password combination"
>     end
>   end
> end
> 
> and in the user model:
> 
> def self.login(name, password)
>   hashed_password = hash_password(password || "")
>   find(:first,
>        :conditions => ["name = ? and hashed_password = ?",
>        name, hashed_password])
>   end
> 
> def try_to_login
>   User.login(self.name, self.password)
> end
> 
> So the login action instantiates a new User object, with the correct
> user name.  It then calls the try_to_login instance method, which calls
> the login class method.
> 
> Why do we need this trickery?  The book calls the code
> "straightforward", but as a Ruby (and OOP) newbie, it''s
not.  Why can''t
> the login action call User.login directly?
> 
> --
> Jay Levitt                |
> Wellesley, MA             | I feel calm.  I feel ready.  I can only
> Faster: jay at jay dot fm | conclude that''s because I
don''t have a
> http://www.jay.fm         | full grasp of the situation. - Mark Adler
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 

-- 
Tobi
http://www.snowdevil.ca - Snowboards that don''t suck
http://typo.leetsoft.com - Open source weblog engine
http://blog.leetsoft.com - Technical weblog