On the rails 3.2 release notes page (http://guides.rubyonrails.org/3_2_release_notes.html), it says:
Deprecated implied layout lookup in controllers whose parent had a explicit layout set
But I tried the following in my rails 3.2.6 app:
class ApplicationController < ActionController::Base
protect_from_forgery
layout "application_main"
end
class HomeController < ApplicationController
def index
#slideshow_pics = Event.get_intro_slide_photos
end
end
with layouts application_main.html.haml and home.html.haml defined and when i go to the home#index page, I get the home.html.haml layout rendered instead of the other.
This seems to go against the deprecation so I was wondering, did one of the releases since 3.2.6 regress the deprecation?
To be even more clear than Dave above, "Deprecated" means: Watch out, we're going to remove this functionality in the future! We're throwing this warning so you pay attention and you better change this soon as we are change how things work!
It doesn't mean that the functionality has already been changed.
Related
I am trying to define some helper methods to be used in the app's controller, but it seems that rails don't even call the controller. just for the test I have the following controller in my app/controllers/my_engine/application_controller.rb and as the documents say rails should find it first and an error should raise because THIS_SHOULD_PRODUCE_ERROR is unknown, but the rspec happily executing without any errors!
class ApplicationController < ActionController::Base
THIS_SHOULD_PRODUCE_ERROR
end
I even tried to mimic the devise's way but the results are the same!
The guide section on the app directory suggests that the application_controller in an engine "will provide any common functionality for the controllers of the engine".
So I wouldn't expect that any additions to that controller will be available to all controllers in an application.
That also means that your application_controller is, I suspect, not getting called when you're running your test. Which would explain why you're not seeing an error.
In terms of how devise does it I think you need to be looking at how define_helpers works. The code you've linked to in your question is the application controller in the test app for the devise gem.
I noticed that I have got things wrong, and the application_controller in the engine does not get applied to application_controller in the app! Also, I couldn't figure out how the devise did it, but I have come up with the simple workaround for this:
require_relative 'controllers/helpers'
module Acu
module Injectors
class << self
ActiveSupport::Notifications.subscribe "start_processing.action_controller" do |**args|
eval((Acu::Configs.get :base_controller).to_s).class_eval do
include Acu::Controllers::Helpers
end
end
end
end
end
This will inject controller helpers to the user's base controller (which I get from the user, default: :ApplicationController) at the end of the class, which is perfect for me (but don't know how to add it to begging of the class if anyone needs it)
Recently I scaffold-ed two of my models/controllers/view, let's call them xxx and yyy. Now I look under the controller file, I see absolutely nothing ! but it was still functioning, upon investigation I found that was due to the
inherited_resources Gem
So the controllers look like this currently
class xxx < InheritedResources::Base
end
so if I change
InheritedResources::Base to ApplicationController
like I have it other controller, would it behave like normal controller ? I tried looking up on the docs, I was referred here for questions.
What is the best way to get normal controller/models back for those two scaffolds ?
Thanks for your time and help.
in config/application.rb add:
#use rails scaffolding generator
config.app_generators.scaffold_controller = :scaffold_controller
When you use InheritedResources, the gem registers a controller generator that generates just that, your controller definition. The point of using InheritedResources::Base is to clean your controllers and move all of the seven REST actions to a common class. You don't need to define any of the following methods if you extend InheritedResources::Base
index
new
create
edit
update
show
destroy
They're all the defined for you. Go ahead and make a test, scaffold a resource and go to it's index method, add a couple records, play around...
Now if you really want to go back to the old way and have your code generated by the bundled controller generator, remove inherited_resources from your Gemfile, bundle install, and generate your scaffolds again.
Hope it helps (:
P.S. if you decide to use InheritedResources (which I suggest you do) you can overwrite any methods you want to customize. Have a look at the docs, everything is more clear over there.
I want to get next thing...
# For ArticlesController > ApplicationController
# in view
render 'articles/edit/form'
# tries 'app/views/articles/edit/_form.html.erb'
# then tries 'app/views/articles/_form.html.erb'
# then what it wants
Or maybe render with array partial option:
# For ArticlesController > ApplicationController
# in view
render_exists ['articles/edit/form', 'articles/new/form']
# tries 'app/views/articles/edit/_form.html.erb'
# then tries 'app/views/articles/new/_form.html.erb'
# then what it wants
This isn't realized, is this? But maybe some gems for 3.2 or monkeypatches... And don't you know pull requests to rails about it? Thanks!
UPD That's isn't controller-based view inheritance. This should work for (at the same page):
render `articles/edit/form`
render `comments/edit/form`
I'm using the mechanism I described in an article in the rails forum
It works a treat for me though I hear there is now some built in support in the latest versions or at least effort is under way to do add such a feature.
That already exists, and it's very similar to the controller inheritance.
You must follow a conventional strategy, however. You would put your global partial in app/views/application, then you can put a more specific one at each inherited level, like app/views/articles.
Take a look at the following railscast for more details: #269 Template Inheritance
I am trying to prepend views to the rails view array e.g.
prepend_view_path("#{Rails.root}/app/views/custom/blah")
This works fine, however in my test suite I keep seeing
DEPRECATION WARNING: process_view_paths is deprecated and will be removed from Rails 3.2.
After a bit of research I see mention of ActionView::PathSet, but cannot find any help searching google or in the Rails API documentation. I need to know how to use this new way of prepending paths in rails 3.2
I would really like to get rid of this warning. Any thoughts?
If it is dynamic (set on a per-request basis):
class ApplicationController < ActionController::Base
before_filter :set_view_path
def set_view_path
prepend_view_path "#{Rails.root}/app/views/custom/blah"
end
end
I think it went to AbstractController::ViewPaths, but still available from controller - should be without deprecation.
If you prepend static fixed path:
# config/application.rb
config.paths.app.views.unshift("#{Rails.root}/app/views/custom/blah")
I'm working on my 1st Ruby on Rails app. I have set up HAML as my formatter and it is rendering views fine.
However, I have a views/layouts/application.html.haml file for the basic layout, but it is not being picked up at all. All I see on the page is may view's HTML.
What could make this fail to be picked up?
Make sure your controller extends ApplicationController and not ActionController::Base.
class SomeController < ApplicationController
can you assert that application.html.erb has been removed from the app/views/layouts directory?