问题
My Rails views and controllers are littered with redirect_to
, link_to
, and form_for
method calls. Sometimes link_to
and redirect_to
are explicit in the paths they're linking (e.g. link_to 'New Person', new_person_path
), but many times the paths are implicit (e.g. link_to 'Show', person
).
I add some single table inheritance (STI) to my model (say Employee < Person
), and all of these methods break for an instance of the subclass (say Employee
); when rails executes link_to @person
, it errors with undefined method employee_path' for #<#<Class:0x000001022bcd40>:0x0000010226d038>
. Rails is looking for a route defined by the class name of the object, which is employee. These employee routes are not defined, and there is no employee controller so the actions aren't defined either.
This question has been asked before:
- At StackOverflow, the answer is to edit every instance of link_to etc in your entire codebase, and state the path explicitly
- On StackOverflow again, two people suggest using
routes.rb
to map the subclass resources to the parent class (map.resources :employees, :controller => 'people'
). The top answer in that same SO question suggests type-casting every instance object in the codebase using.becomes
- Yet another one at StackOverflow, the top answer is way in the Do Repeat Yourself camp, and suggests creating duplicate scaffolding for every subclass.
- Here's the same question again at SO, where the top answer seems to just be wrong (Rails magic Just Works!)
- Elsewhere on the web, I found this blog post where F2Andy recommends editing in the path everywhere in the code.
- On the blog post Single Table Inheritance and RESTful Routes at Logical Reality Design, it is recommended to map the resources for the subclass to the superclass controller, as in SO answer number 2 above.
- Alex Reisner has a post Single Table Inheritance in Rails, in which he advocates against mapping the resources of the child classes to the parent class in
routes.rb
, since that only catches routing breakages fromlink_to
andredirect_to
, but not fromform_for
. So he recommends instead adding a method to the parent class to get the subclasses to lie about their class. Sounds good, but his method gave me the errorundefined local variable or method `child' for #
.
So the answer that seems most elegant and has the most consensus (but it's not all that elegant, nor that much consensus), is the add the resources to your routes.rb
. Except this doesn't work for form_for
. I need some clarity! To distill the choices above, my options are
- map the resources of the subclass to the controller of the superclass in
routes.rb
(and hope I don't need to call form_for on any subclasses) - Override rails internal methods to make the classes lie to each other
- Edit every instance in the code where the path to an object's action is invoked implicitly or explicitly, either changing the path or type-casting the object.
With all these conflicting answers, I need a ruling. It seems to me like there is no good answer. Is this a failing in rails' design? If so, is it a bug that may get fixed? Or if not, then I'm hoping someone can set me straight on this, walk me through the pros and cons of each option (or explain why that's not an option), and which one is the right answer, and why. Or is there a right answer that I'm not finding on the web?
回答1:
This is the simplest solution I was able to come up with with minimal side effect.
class Person < Contact
def self.model_name
Contact.model_name
end
end
Now url_for @person
will map to contact_path
as expected.
How it works: URL helpers rely on YourModel.model_name
to reflect upon the model and generate (amongst many things) singular/plural route keys. Here Person
is basically saying I'm just like Contact
dude, ask him.
回答2:
I had the same problem. After using STI, the form_for
method was posting to the wrong child url.
NoMethodError (undefined method `building_url' for
I ended up adding in the extra routes for the child classes and pointing them to the same controllers
resources :structures
resources :buildings, :controller => 'structures'
resources :bridges, :controller => 'structures'
Additionally:
<% form_for(@structure, :as => :structure) do |f| %>
in this case structure is actually a building (child class)
It seems to work for me after doing a submit with form_for
.
回答3:
I suggest you take a look at : https://stackoverflow.com/a/605172/445908, using this method will enable you to use "form_for".
ActiveRecord::Base#becomes
回答4:
Use type in the routes:
resources :employee, controller: 'person', type: 'Employee'
http://samurails.com/tutorial/single-table-inheritance-with-rails-4-part-2/
回答5:
Following the idea of @Prathan Thananart but trying to not destroy nothing. (since there is so much magic involved)
class Person < Contact
model_name.class_eval do
def route_key
"contacts"
end
def singular_route_key
superclass.model_name.singular_route_key
end
end
end
Now url_for @person will map to contact_path as expected.
回答6:
I was having trouble with this problem too and came by this answer on a question similar to ours. It worked for me.
form_for @list.becomes(List)
Answer shown here: Using STI path with same controller
The .becomes
method is defined as mainly used for solving STI problems like your form_for
one.
.becomes
info here: http://apidock.com/rails/ActiveRecord/Base/becomes
Super late response, but this is the best answer I could find and it worked well for me. Hope this helps some one. Cheers!
回答7:
Ok, Ive had a ton of frustration in this area of Rails, and have arrived at the following approach, perhaps this will help others.
Firstly be aware that a number of solutions above and around the net suggest using constantize on client provided parameters. This is a known DoS attack vector as Ruby does not garbage collect symbols, thus allowing an attacker to create arbitrary symbols and consume available memory.
I've implemented the approach below which supports instantiation of model subclasses, and is SAFE from the contantize problem above. It is very similar to what rails 4 does, but also allows more than one level of subclassing (unlike Rails 4) and works in Rails 3.
# initializers/acts_as_castable.rb
module ActsAsCastable
extend ActiveSupport::Concern
module ClassMethods
def new_with_cast(*args, &block)
if (attrs = args.first).is_a?(Hash)
if klass = descendant_class_from_attrs(attrs)
return klass.new(*args, &block)
end
end
new_without_cast(*args, &block)
end
def descendant_class_from_attrs(attrs)
subclass_name = attrs.with_indifferent_access[inheritance_column]
return nil if subclass_name.blank? || subclass_name == self.name
unless subclass = descendants.detect { |sub| sub.name == subclass_name }
raise ActiveRecord::SubclassNotFound.new("Invalid single-table inheritance type: #{subclass_name} is not a subclass of #{name}")
end
subclass
end
def acts_as_castable
class << self
alias_method_chain :new, :cast
end
end
end
end
ActiveRecord::Base.send(:include, ActsAsCastable)
After trying various approaches for the 'sublclass loading in devlopment issue' many similar to whats suggested above, I found the only thing that worked reliably was to use 'require_dependency' in my model classes. This ensures that class loading works properly in development and causes no issues in production. In development, without 'require_dependency' AR wont know about all subclasses, which impacts the SQL emitted for matching on the type column. In addition without 'require_dependency' you can also end up in a situation with multiple versions of the model classes at the same time! (eg. this can happen when you change a base or intermediate class, the sub-classes don't always seem to reload and are left subclassing from the old class)
# contact.rb
class Contact < ActiveRecord::Base
acts_as_castable
end
require_dependency 'person'
require_dependency 'organisation'
I also don't override model_name as suggested above because I use I18n and need different strings for the attributes of different subclasses, eg :tax_identifier becomes 'ABN' for Organisation, and 'TFN' for Person (in Australia).
I also use route mapping, as suggested above, setting the type:
resources :person, :controller => 'contacts', :defaults => { 'contact' => { 'type' => Person.sti_name } }
resources :organisation, :controller => 'contacts', :defaults => { 'contact' => { 'type' => Organisation.sti_name } }
In addition to the route mapping, I'm using InheritedResources and SimpleForm and I use the following generic form wrapper for new actions:
simple_form_for resource, as: resource_request_name, url: collection_url,
html: { class: controller_name, multipart: true }
... and for edit actions:
simple_form_for resource, as: resource_request_name, url: resource_url,
html: { class: controller_name, multipart: true }
And to make this work, in my base ResourceContoller I expose InheritedResource's resource_request_name as a helper method for the view:
helper_method :resource_request_name
If you're not using InheritedResources, then use something like the following in your 'ResourceController':
# controllers/resource_controller.rb
class ResourceController < ApplicationController
protected
helper_method :resource
helper_method :resource_url
helper_method :collection_url
helper_method :resource_request_name
def resource
@model
end
def resource_url
polymorphic_path(@model)
end
def collection_url
polymorphic_path(Model)
end
def resource_request_name
ActiveModel::Naming.param_key(Model)
end
end
Always happy to hear others experiences and improvements.
回答8:
I recently documented my attempts to get a stable STI pattern working in a Rails 3.0 app. Here's the TL;DR version:
# app/controllers/kase_controller.rb
class KasesController < ApplicationController
def new
setup_sti_model
# ...
end
def create
setup_sti_model
# ...
end
private
def setup_sti_model
# This lets us set the "type" attribute from forms and querystrings
model = nil
if !params[:kase].blank? and !params[:kase][:type].blank?
model = params[:kase].delete(:type).constantize.to_s
end
@kase = Kase.new(params[:kase])
@kase.type = model
end
end
# app/models/kase.rb
class Kase < ActiveRecord::Base
# This solves the `undefined method alpha_kase_path` errors
def self.inherited(child)
child.instance_eval do
def model_name
Kase.model_name
end
end
super
end
end
# app/models/alpha_kase.rb
# Splitting out the subclasses into separate files solves
# the `uninitialize constant AlphaKase` errors
class AlphaKase < Kase; end
# app/models/beta_kase.rb
class BetaKase < Kase; end
# config/initializers/preload_sti_models.rb
if Rails.env.development?
# This ensures that `Kase.subclasses` is populated correctly
%w[kase alpha_kase beta_kase].each do |c|
require_dependency File.join("app","models","#{c}.rb")
end
end
This approach gets around the problems that you list as well as a number of other issues that others have had with STI approaches.
回答9:
You can try this, if you have no nested routes:
resources :employee, path: :person, controller: :person
Or you can go another way and use some OOP-magic like described here: https://coderwall.com/p/yijmuq
In second way you can make similar helpers for all your nested models.
回答10:
Here is a safe clean way to have it work in forms and throughout your application that we use.
resources :districts
resources :district_counties, controller: 'districts', type: 'County'
resources :district_cities, controller: 'districts', type: 'City'
Then I have in my form. The added piece for this is the as: :district.
= form_for(@district, as: :district, html: { class: "form-horizontal", role: "form" }) do |f|
Hope this helps.
回答11:
If I consider an STI inheritance like this:
class AModel < ActiveRecord::Base ; end
class BModel < AModel ; end
class CModel < AModel ; end
class DModel < AModel ; end
class EModel < AModel ; end
in 'app/models/a_model.rb' I add:
module ManagedAtAModelLevel
def model_name
AModel.model_name
end
end
And then in the AModel class:
class AModel < ActiveRecord::Base
def self.instanciate_STI
managed_deps = {
:b_model => true,
:c_model => true,
:d_model => true,
:e_model => true
}
managed_deps.each do |dep, managed|
require_dependency dep.to_s
klass = dep.to_s.camelize.constantize
# Inject behavior to be managed at AModel level for classes I chose
klass.send(:extend, ManagedAtAModelLevel) if managed
end
end
instanciate_STI
end
Therefore I can even easily choose which model I want to use the default one, and this without even touching the sub class definition. Very dry.
回答12:
This way works for me ok (define this method in the base class):
def self.inherited(child)
child.instance_eval do
alias :original_model_name :model_name
def model_name
Task::Base.model_name
end
end
super
end
回答13:
You can create method that returns dummy Parent object for routing purpouse
class Person < ActiveRecord::Base
def routing_object
Person.new(id: id)
end
end
and then simply call form_for @employee.routing_object which without type will return Person class object
回答14:
Following @prathan-thananart answer, and for the multiple STI classes, you can add the following to the parent model ->
class Contact < ActiveRecord::Base
def self.model_name
ActiveModel::Name.new(self, nil, 'Contact')
end
end
That will make each form with Contact data to send params as params[:contact]
instead of params[:contact_person]
, params[:contact_whatever]
.
回答15:
hackish,but just another one to the list of solutions.
class Parent < ActiveRecord::Base; end
Class Child < Parent
def class
Parent
end
end
works on rails 2.x and 3.x
来源:https://stackoverflow.com/questions/4507149/best-practices-to-handle-routes-for-sti-subclasses-in-rails