Error (nil object) on object creation

Greetings,

Can anyone shed some light on why the following error is raised? I’ve
depleted my small inventory of ideas.

Thanks much.

Bill


NoMethodError in IncidentController#signup

You have a nil object when you didn’t expect it!
The error occurred while evaluating nil.request

RAILS_ROOT: C:/RubyRails/rails_apps/rappEAH

C:/RubyRails/ruby/lib/ruby/gems/1.8/gems/actionpack-2.0.2/lib/
action_controller/mime_responds.rb:114:in initialize' app/controllers/incident_controller.rb:19:innew’
app/controllers/incident_controller.rb:19:in signup' -e:3:inload’
-e:3

class IncidentController < ApplicationController
def signup
@title = “register”
#following is the offending line
@responder = Responder.new(params[:responder])

end
end #end class

First, I would expect to see a plural here:
class IncidentsController < ApplicationController
May not seem like much but convention is important here.

The :responder that appears in your line:
@responder = Responder.new(params[:responder])
would typically be passed in as a field in the url that points to this
controller/action.

If you run:
rake routes
you should see a line that contains something like:
incident GET /incidents/:responder(.:format) {:controller =>
“incidents”, :action => “show”}
and the parameter :responder would have been explicitly set by you (or
implicitly by link_to helper method), possibly in the file views/
incidents/index.html.erb.

Hello Rick and thanks for answering,

I’m feeling rather muddled. In my brief ROR history I’ve been working
under the assumption that naming conventions called for controllers to
be in the singular. Of course I’m finding out that much has been
deprecated. So would you please confirm that controller names are
supposed to be plural.

Regarding @responder = Responder.new(params[:responder])
Since models and tables are “routeless”, I’m not clear why routing
should be an issue here. And I thought that if the params hash is
empty, I will get an empty @responder object which is what I expect in
this case.

I appreciate any further help you can offer.

Cheers, Bill

I’m going to vent a bit of frustration here. 1. As fast as I learn
something, I learn that it has changed or deprecated. Aaargh! 2. I
had a suspicion that the singular/plural convention was a lot of
silliness and the changes seem to vindicate this view. 3. REST
appears to have good intentions, but is generally too limiting in
practice and hence requires workarounds that make swiss cheese of the
concept. 4. I am worried that the continuous flux as ROR matures is
going to mean a short life expectancy for applications. 5.
Documentation is abominable or good documentation is scarce.

Frustrations aside I feel much better because you were spot on, Rick
D. Responder is a model and qualifying the name resolved the
problem.

I’m still unclear as to why there was a “name clash” since there is
only one class named Responder whether this namespace or elsewhere.
But I greatly appreciate all of the the guidance, help and patience
from both Ricks’. A little piece of my sanity is in debt to you.

Cheers, Bill

On Thu, Sep 3, 2009 at 11:14 AM, zambezi[email protected]
wrote:

Hello Rick and thanks for answering,

I’m feeling rather muddled. In my brief ROR history I’ve been working
under the assumption that naming conventions called for controllers to
be in the singular. Of course I’m finding out that much has been
deprecated. So would you please confirm that controller names are
supposed to be plural.

This is a different Rick

Since Rails became Restful, it’s more common to have plural controller
names since this is the default when generating routes using
map.resources (and even map.resource).

Regarding @responder = Responder.new(params[:responder])
Since models and tables are “routeless”, I’m not clear why routing
should be an issue here. And I thought that if the params hash is
empty, I will get an empty @responder object which is what I expect in
this case.

I appreciate any further help you can offer.

I think you’ve run into another unfortunately name clash.

I’m assuming that you have a model called Responder, unfortunately it
looks like in your controller in the line

@responder = Responder.new(params[:responder])

Responder is actually resolving to
ActionController::MimeResponds::Responder

You might try something like

@responder = ::Responder.new(params[:responder])

to force Ruby to look in the outermost namespace.


Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

2009/9/3 Frederick C. [email protected]:

But I greatly appreciate all of the the guidance, Â help and patience
from both Ricks’. Â A little piece of my sanity is in debt to you.

No, there is a Responder class that is part of Rails, and ruby’s
constant lookup rules made it find the one that is hidden inside
ActionController before it found your top level one

Responder is not on the list of problem words at
http://wiki.rubyonrails.org/rails/pages/ReservedWords. Perhaps
someone with access could add it.

Colin

On Sep 3, 6:47 pm, zambezi [email protected] wrote:

Frustrations aside I feel much better because you were spot on, Rick
D. Responder is a model and qualifying the name resolved the
problem.

I’m still unclear as to why there was a “name clash” since there is
only one class named Responder whether this namespace or elsewhere.
But I greatly appreciate all of the the guidance, help and patience
from both Ricks’. A little piece of my sanity is in debt to you.

No, there is a Responder class that is part of Rails, and ruby’s
constant lookup rules made it find the one that is hidden inside
ActionController before it found your top level one

Fred

On Sep 4, 2009, at 3:33 AM, Colin L. wrote:

from both Ricks’. A little piece of my sanity is in debt to you.
Colin
Anyone who registers has “access” (but don’t worry about it because I
added it for you).

-Rob

Rob B. http://agileconsultingllc.com
[email protected]

2009/9/4 Rob B. [email protected]:

Anyone who registers has “access” (but don’t worry about it because I
added it for you).

OK, thanks, I did not realise that. I had better register.

Colin

zambezi, it’s a lot better than it used to be. Documentation is also a
lot better.
http://api.rubyonrails.org/

On Thu, Sep 3, 2009 at 5:25 PM, Frederick
Cheung[email protected] wrote:

But I greatly appreciate all of the the guidance, help and patience
from both Ricks’. A little piece of my sanity is in debt to you.

No, there is a Responder class that is part of Rails, and ruby’s
constant lookup rules made it find the one that is hidden inside
ActionController before it found your top level one

And how did I figure that out, the OP might ask.

Look at the walkback:

You have a nil object when you didn’t expect it!
The error occurred while evaluating nil.request

RAILS_ROOT: C:/RubyRails/rails_apps/rappEAH

C:/RubyRails/ruby/lib/ruby/gems/1.8/gems/actionpack-2.0.2/lib/
action_controller/mime_responds.rb:114:in initialize' app/controllers/incident_controller.rb:19:innew’
app/controllers/incident_controller.rb:19:in `signup’

The actual error happened in the file
action_controller/mime_responds.rb which raised my suspicions.

So I looked at the source code, which is in the actionpack gem (the
one which has the code for action_controller and action_view, and le
voila!


Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

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