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

On Feb 2, 5:00 pm, DBA [email protected] wrote:

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?

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

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

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

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

Diogo D. 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.

On Mon, Feb 8, 2010 at 7:50 PM, Aldric G. [email protected]
wrote:

   flash[:notice] = 'Report was successfully created.'


Regards:
Rajeev sharma
+919813270707

Diogo D. 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?

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs