ruby on rails - Mejores prácticas para manejar rutas de subclases de ITS en rieles

ruby-on-rails single-table-inheritance

Question

Las vistas y los controladores de My Rails están llenos de redirect_to , link_to y form_for llamadas a métodos. A veces link_to y redirect_to son explícitos en las rutas que están vinculando (por ejemplo, link_to ''New Person'', new_person_path ), pero muchas veces las rutas están implícitas (por ejemplo, link_to ''Show'', person ).

Agrego alguna herencia de tabla única (STI) a mi modelo (digamos Employee < Person ), y todos estos métodos se rompen para una instancia de la subclase (digamos Employee ); cuando Rails ejecuta link_to @person , se link_to @person un error con el undefined method employee_path'' for #<#<Class:0x000001022bcd40>:0x0000010226d038> . Rails está buscando una ruta definida por el nombre de clase del objeto, que es empleado. Estas rutas de empleados no están definidas, y no hay un controlador de empleado, por lo que las acciones tampoco están definidas.

Esta pregunta se ha hecho antes:

1. En StackOverflow , la respuesta es editar cada instancia de link_to, etc. en toda su base de código, y declarar explícitamente la ruta
2. En StackOverflow nuevamente, dos personas sugieren usar routes.rb para asignar los recursos de la subclase a la clase padre ( map.resources :employees, :controller => ''people'' ). La respuesta principal en la misma pregunta de SO sugiere que se .becomes en cada objeto de instancia en la base de código con .becomes
3. Otro más en StackOverflow , la respuesta más importante está en el campo Do Repetir usted mismo, y sugiere crear andamios duplicados para cada subclase.
4. Here''s la misma pregunta nuevamente en SO, donde la respuesta principal parece estar equivocada (Rails magic Just Works!)
5. En otra parte de la web, encontré esta publicación de blog donde F2Andy recomienda editar en la ruta en todas partes del código.
6. En la publicación de blog Single Table Herencia y Rutas RESTful en Logical Reality Design, se recomienda asignar los recursos para la subclase al controlador de superclase, como en la respuesta SO número 2 anterior.
7. Alex Reisner tiene una herencia de tabla única en Rails , en la que defiende el mapeo de los recursos de las clases secundarias a la clase padre en routes.rb , ya que solo atrapa las roturas de enrutamiento de link_to y redirect_to , pero no de form_for . Por lo tanto, recomienda en su lugar agregar un método a la clase principal para que las subclases mientan sobre su clase. Suena bien, pero su método me dio el error de undefined local variable or method `child'' for # .

Entonces, la respuesta que parece más elegante y tiene más consenso (pero no es tan elegante, ni mucho consenso), es agregar los recursos a sus routes.rb . Excepto que esto no funciona para form_for . Necesito algo de claridad! Para destilar las opciones anteriores, mis opciones son

1. mapear los recursos de la subclase al controlador de la superclase en routes.rb (y espero no tener que llamar a form_for en ninguna subclase)
2. Anula los métodos internos de los rieles para hacer que las clases se encuentren entre sí
3. Edite cada instancia en el código donde la ruta a la acción de un objeto se invoca implícita o explícitamente, ya sea cambiando la ruta o lanzando el objeto.

Con todas estas respuestas contradictorias, necesito un fallo. Me parece que no hay una buena respuesta. ¿Esto está fallando en el diseño de los rieles? Si es así, ¿es un error que puede solucionarse? O si no, entonces espero que alguien me pueda aclarar esto, guiarme a través de los pros y los contras de cada opción (o explicar por qué no es una opción), y cuál es la respuesta correcta, y por qué. ¿O hay una respuesta correcta que no estoy encontrando en la web?

Answer 1

Aquí hay una forma segura y limpia de que funcione en los formularios y en toda la aplicación que usemos.

resources :districts
resources :district_counties, controller: ''districts'', type: ''County''
resources :district_cities, controller: ''districts'', type: ''City''

Entonces tengo en mi forma. La pieza añadida para esto es el as:: distrito.

= form_for(@district, as: :district, html: { class: "form-horizontal",         role: "form" }) do |f|

Espero que esto ayude.

Answer 2

De esta manera me funciona bien (define este método en la clase base):

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

Answer 3

Esta es la solución más simple que pude obtener con un mínimo efecto secundario.

class Person < Contact
  def self.model_name
    Contact.model_name
  end
end

Ahora url_for @person se correlacionará con contact_path como se esperaba.

Cómo funciona: los helpers de URL confían en YourModel.model_name para reflejar el modelo y generar (entre muchas cosas) claves de ruta singular / plural. Aquí la Person básicamente dice que soy como Contact amigo, pregúntale .

Answer 4

Le sugiero que eche un vistazo a: https://.com/a/605172/445908 , utilizando este método le permitirá usar "form_for".

ActiveRecord::Base#becomes

Answer 5

Ok, he tenido mucha frustración en esta área de Rails, y he llegado al siguiente enfoque, quizás esto ayudará a otros.

En primer lugar, tenga en cuenta que una serie de soluciones por encima y alrededor de la red sugieren el uso de la constante en los parámetros proporcionados por el cliente. Este es un conocido vector de ataque DoS, ya que Ruby no recolecta símbolos, lo que permite a un atacante crear símbolos arbitrarios y consumir memoria disponible.

Implementé el siguiente enfoque que admite la creación de instancias de subclases modelo, y es SEGURO desde el problema de contantizar anterior. Es muy similar a lo que hace rails 4, pero también permite más de un nivel de subclases (a diferencia de Rails 4) y funciona en 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)

Después de probar varios enfoques para la ''carga subclase en el problema de desarrollo'', muchos similares a los sugeridos anteriormente, descubrí que lo único que funcionaba de manera confiable era usar ''require_dependency'' en mis clases modelo. Esto asegura que la carga de clases funciona correctamente en el desarrollo y no causa problemas en la producción. En desarrollo, sin ''require_dependency'', AR no conocerá todas las subclases, lo que afecta el SQL emitido para la coincidencia en la columna de tipo. ¡Además, sin ''require_dependency'', también puede terminar en una situación con múltiples versiones de las clases modelo al mismo tiempo! (por ejemplo, esto puede suceder cuando se cambia una clase base o intermedia, las subclases no siempre parecen recargarse y se dejan subclases de la clase anterior)

# contact.rb
class Contact < ActiveRecord::Base
  acts_as_castable
end

require_dependency ''person''
require_dependency ''organisation''

Tampoco anulo model_name como se sugiere arriba porque uso I18n y necesito diferentes cadenas para los atributos de diferentes subclases, por ejemplo: tax_identifier se convierte en ''ABN'' para Organización y ''TFN'' para Persona (en Australia).

También uso el mapeo de ruta, como se sugirió anteriormente, estableciendo el tipo:

resources :person, :controller => ''contacts'', :defaults => { ''contact'' => { ''type'' => Person.sti_name } }
resources :organisation, :controller => ''contacts'', :defaults => { ''contact'' => { ''type'' => Organisation.sti_name } }

Además del mapeo de ruta, estoy usando InheritedResources y SimpleForm y utilizo el siguiente wrapper de formulario genérico para nuevas acciones:

simple_form_for resource, as: resource_request_name, url: collection_url,
      html: { class: controller_name, multipart: true }

... y para las acciones de edición:

simple_form_for resource, as: resource_request_name, url: resource_url,
      html: { class: controller_name, multipart: true }

Y para que esto funcione, en mi ResourceContoller base expongo el resource_request_name de InheritedResource como un método auxiliar para la vista:

helper_method :resource_request_name 

Si no está utilizando InheritedResources, entonces use algo como lo siguiente en su ''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

Siempre feliz de escuchar otras experiencias y mejoras.

Answer 6

Puede crear un método que devuelva un objeto principal ficticio para el enrutamiento.

class Person < ActiveRecord::Base      
  def routing_object
    Person.new(id: id)
  end
end

y luego simplemente llame a form_for @ employee.routing_object que sin tipo devolverá el objeto de la clase Person

Answer 7

Puedes intentar esto, si no tienes rutas anidadas:

resources :employee, path: :person, controller: :person

O puede ir de otra manera y usar algo de OOP-magic como se describe aquí: https://coderwall.com/p/yijmuq

En una segunda forma, puedes hacer ayudantes similares para todos tus modelos anidados.

Answer 8

Recientemente documented mis intentos de obtener un patrón STI estable trabajando en una aplicación Rails 3.0. Aquí está la versión TL; DR:

# 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

Este enfoque evita los problemas que enumera, así como una serie de otros problemas que otros han tenido con los enfoques de ITS.

Answer 9

Si considero una herencia de ITS como esta:

class AModel < ActiveRecord::Base ; end
class BModel < AModel ; end
class CModel < AModel ; end
class DModel < AModel ; end
class EModel < AModel ; end

en ''app / models / a_model.rb'' agrego:

module ManagedAtAModelLevel
  def model_name
    AModel.model_name
  end
end

Y luego en la clase AModel:

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

Por lo tanto, incluso puedo elegir fácilmente qué modelo quiero usar por defecto, y esto sin siquiera tocar la definición de la clase secundaria. Muy seco.

Answer 10

Siguiendo la idea de @Prathan Thananart, pero tratando de no destruir nada. (ya que hay tanta magia involucrada)

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

Ahora url_for @person se correlacionará con contact_path como se esperaba.

Answer 11

También estaba teniendo problemas con este problema y obtuve esta respuesta en una pregunta similar a la nuestra. Funcionó para mí

form_for @list.becomes(List)

Respuesta que se muestra aquí: Uso de la ruta STI con el mismo controlador

El método .becomes se define como el más utilizado para resolver problemas de ITS como su form_for uno.

.becomes clic aquí: http://apidock.com/rails/ActiveRecord/Base/becomes

Súper tardía respuesta, pero esta es la mejor respuesta que pude encontrar y funcionó bien para mí. Espero que esto ayude a alguien. ¡Aclamaciones!

Answer 12

Use tipo en las rutas:

resources :employee, controller: ''person'', type: ''Employee'' 

http://samurails.com/tutorial/single-table-inheritance-with-rails-4-part-2/

Answer 13

Yo tuve el mismo problema. Después de usar STI, el método form_for se estaba publicando en la url secundaria incorrecta.

NoMethodError (undefined method `building_url'' for

Terminé añadiendo las rutas adicionales para las clases secundarias y apuntándolas a los mismos controladores

 resources :structures
 resources :buildings, :controller => ''structures''
 resources :bridges, :controller => ''structures''

Adicionalmente:

<% form_for(@structure, :as => :structure) do |f| %>

en este caso, la estructura es en realidad un edificio (clase infantil)

Parece que me funciona después de enviar un formulario con form_for .

Answer 14

hackish, pero solo otro más a la lista de soluciones.

class Parent < ActiveRecord::Base; end

Class Child < Parent
  def class
    Parent
  end
end

funciona en los carriles 2.xy 3.x