render :action => 'new' renders a blank page

Hello,

Even though I'm quite a newbie in Ruby and Ruby on Rails, I've been
trying to fix Binarylogic's authlogic-openid gem, over on
http://github.com/DBA/authlogic_openid, which is current version is
incredibly outdated due to the upgrades made to the rails/
open_id_authentication plugin.

So far, I've managed to get the registration (new account) process to
work when the user provides a valid OpenID. However, when he enters a
value like ".." a message is set on @user.errors.on
(:openid_identifier) but the render :action => 'new' renders a blank
screen, for a reason that I'm yet to understand.

Here's my UserController#create

  def create
    @user = User.new(params[:user])
    @user.save do |result|
      if result
        flash[:notice] = "Registration successfull."
        redirect_to root_url
      else
        render :action => 'new'
      end
    end
  end

As mentioned, it works great when the user enters a valid openid. The
save block is yield by acts_as_authentic:

      def save(perform_validation = true, &block)
        return false if perform_validation &&
authenticate_with_openid? && !authenticate_with_openid
        return false if new_record? && (!openid_complete? &&
@openid_error.nil?)

        result = super
        yield(result) unless block.nil?
        result
      end

However, when the openid_identifer validation kicks in, something in
the "supper" is preventing the render :action => 'new' set in the
controller for when the result is not "true".

I'm a bit new on this kind of issues, so bare with me on this
eventually newbie question... Could someone give me some guidance on
why invoking the super on the save method is making it impossible to
render the new action in order to show the user his error messages?

Best regards,
DBA

Are you sure the problem isn't a few lines further up ? If either of
those return false statements are triggered then save won't yield to
its block. Would it not be simpler to use the return value from save
rather than this block approach?

Fred

Are you sure the problem isn't a few lines further up ? If either of
those return false statements are triggered then save won't yield to
its block. Would it not be simpler to use the return value from save
rather than this block approach?

The block approach was originally implemented by Binarylogic and the
console logs show that even when the input is invalid (thus there's an
error set for the user.openid_identifier) the save method block is
yielded.

Here's the console log for an invalid output:

Processing UsersController#create (for 127.0.0.1 at 2010-02-02
16:32:23) [POST]
  Parameters: {"commit"=>"Create", "action"=>"create",
"authenticity_token"=>"Q/IDQDxzVUdbCO/fDp1Swgei+hmXJbadWrfRknxxID8=",
"controller"=>"users", "user"=>{"password_confirmation"=>"[FILTERED]",
"username"=>"", "openid_identifier"=>"..", "password"=>"[FILTERED]",
"email"=>""}}
  User Load (0.2ms) SELECT "users".id FROM "users" WHERE (LOWER
("users"."username") = '') LIMIT 1
  User Load (0.1ms) SELECT "users".id FROM "users" WHERE (LOWER
("users"."email") = '') LIMIT 1
  User Load (0.1ms) SELECT "users".id FROM "users" WHERE
("users"."openid_identifier" = '..') LIMIT 1
  CACHE (0.0ms) SELECT "users".id FROM "users" WHERE (LOWER
("users"."email") = '') LIMIT 1
  CACHE (0.0ms) SELECT "users".id FROM "users" WHERE (LOWER
("users"."username") = '') LIMIT 1
  User Load (0.1ms) SELECT "users".id FROM "users" WHERE
("users"."persistence_token" =
'8e5760baab016edfbf616d742624371e8a2634e4e337200cbe49e11bc32ff82cdad306b6c3ae1fcd4eb76a28cfde0cc70dcbdf6070a4c511f75b510076b45f7b')
LIMIT 1
  User Load (0.1ms) SELECT "users".id FROM "users" WHERE
("users"."single_access_token" = 'IM0pySoQJaARTzKFYEHc') LIMIT 1
Rendering template within layouts/application
Rendering users/new
Rendered users/_form (15.6ms)
Completed in 25ms (View: 17, DB: 0) | 200 OK [http://localhost/users]

Before the rendering I've traced the request in debug mode and created
a gist with the output of my actions, where clearly the request to
render the 'new' action is processed and the errors are correctly set
(by the save method): http://gist.github.com/292936

Any idea of what might be causing this issue? I can try to debug the
render method but it's just "to internal to my current rails
knowledge" :slight_smile:

Best regards,
DBA

Other than a shameless bump, anyone else has any ideas on how can I
solve this issue so we can have a working openid gem for Authlogic?

Best regards,
DBA

Diogo Delgado wrote:

Other than a shameless bump, anyone else has any ideas on how can I
solve this issue so we can have a working openid gem for Authlogic?

Best regards,
DBA

So.. Where's your fork of the code so we can take a look?

The fork code is available at: http://github.com/DBA/authlogic_openid

Diogo Delgado wrote:

The fork code is available at: http://github.com/DBA/authlogic_openid

I'm taking a look at the automatically generated content:

  def create
    @report = Report.new(params[:report])

    respond_to do |format|
      if @report.save
        flash[:notice] = 'Report was successfully created.'
        format.html { redirect_to(@report) }
        format.xml { render :xml => @report, :status => :created,
:location => @report }
      else
        format.html { render :action => "new" }
        format.xml { render :xml => @report.errors, :status =>
:unprocessable_entity }
      end
    end
  end

Why don't you let your code look a little more like that, and let us
know?

is there is new.rhtml or new.html.erb in yours app.