I want to put a ‘search_box’ text_field in the header of each page.
This
common header template is implemented in
‘views/layouts/application.rhtml’.
The search_box is implemented in a controller named ‘users’.
(so ApplicationController is calling an :action in UserController)
When I add this line to my ‘controllers/application.rb’ file, I don’t
understand why I get an ‘undefined method’ error. After all, “class
ApplicationController < ActionController::Base”.
@sbox = render_component_as_string(:controller=>‘users’,
:action=>:search)
This problem was also described in a post to this list 6 months ago:
http://lists.rubyonrails.org/pipermail/rails/2006-February/016759.html
Nobody replied. I corresponded with the February poster, who points out
that render_component_as_string() is ‘protected’, and suggests that is
why
Controller_A can’t call an Action in Controller_B. But some folks on the
Site5 forums, as well as the book authors (Dave T., Chad F.)
claim
to make cross-controller calls. And if cross-controller invocations
simply
didn’t work, the whole point of Components would be greatly diminished.
I also read this nice ‘components’ doc
http://manuals.rubyonrails.com/read/chapter/71
…
which does not make it clear if both ‘render_component’ and
‘render_component_as_string’ can both be called from either a View or
Controller. I think the doc is saying that either method can be called
from either location. So why is it ‘undefined’?
It seems strange to me that the WEBrick logs shows the pages being
produced
with back-rev gem libraries - for example, actionpack-1.12.1 instead of
1.12.5. But I do find support for render_component_as_string even in
the
“…1” version library. So perphaps this is odd, but not the cause of
the
problem? (I’m running 64-bit CentOS, Rails 1.1.6)
======================================
NoMethodError (undefined method render_component_as_string' for ApplicationController:Class): /app/controllers/application.rb:11 /usr/lib64/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:140:inload’
/usr/lib64/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:56:in
require_or_load' /usr/lib64/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:30:independ_on’
/usr/lib64/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:85:in
require_dependency' /usr/lib64/ruby/gems/1.8/gems/rails-1.1.2/lib/dispatcher.rb:69:inprepare_application’
/usr/lib64/ruby/gems/1.8/gems/rails-1.1.2/lib/dispatcher.rb:37:in
dispatch' /usr/lib64/ruby/gems/1.8/gems/rails-1.1.2/lib/webrick_server.rb:115:inhandle_dispatch’
/usr/lib64/ruby/gems/1.8/gems/rails-1.1.2/lib/webrick_server.rb:81:in
service' /usr/lib64/ruby/1.8/webrick/httpserver.rb:104:inservice’
/usr/lib64/ruby/1.8/webrick/httpserver.rb:65:in run' /usr/lib64/ruby/1.8/webrick/server.rb:173:instart_thread’
/usr/lib64/ruby/1.8/webrick/server.rb:162:in start_thread' /usr/lib64/ruby/1.8/webrick/server.rb:95:instart’
/usr/lib64/ruby/1.8/webrick/server.rb:92:in start' /usr/lib64/ruby/1.8/webrick/server.rb:23:instart’
/usr/lib64/ruby/1.8/webrick/server.rb:82:in start' /usr/lib64/ruby/gems/1.8/gems/rails-1.1.2/lib/webrick_server.rb:67:indispatch’
/usr/lib64/ruby/gems/1.8/gems/rails-1.1.2
/lib/commands/servers/webrick.rb:59
/usr/lib64/site_ruby/1.8/rubygems/custom_require.rb:21:in require' /usr/lib64/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:147:inrequire’
/usr/lib64/ruby/gems/1.8/gems/rails-1.1.2/lib/commands/server.rb:30
/usr/lib64/site_ruby/1.8/rubygems/custom_require.rb:21:in require' /usr/lib64/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:147:inrequire’
i 08-14 17:55:47 Rendering
/usr/lib64/ruby/gems/1.8/gems/actionpack-1.12.1/lib/action_controller/templates/rescues/layout.rhtml
(500 Internal Error)
I still don’t know why WEBrick and Mongrel were so fond of back-rev
libs,
but running “gem cleanup” got rid of all but the most recent ones.