ruby-on-rails - ejemplos - ruby on rails que es

Resumen de los conceptos fundamentales de Ruby on Rails

Question

Siendo nuevo en Rails, estoy teniendo dificultades para encontrar un sitio web o referencia que ofrezca un resumen de Ruby on Rails. Entiendo MVC, ActiveRecord y ese tipo de cosas en un nivel básico, pero me está costando entender algunas de las relaciones y los fundamentos. Por ejemplo:

1. ¿Cuáles son todas las convenciones de nombres que necesito conocer?
2. ¿Cómo deberían estructurarse y nombrarse las acciones del controlador?
3. ¿Cuáles son las mejores formas de presentar información en una vista (a través de :content_for o render a partial) y cuáles son las formas que no debo usar?
4. ¿Qué debería ser un ayudante y qué no?
5. ¿Cuáles son las dificultades comunes o algo que necesito hacer correctamente desde el principio?
6. ¿Cómo se puede modularizar el código? ¿Para eso está la carpeta lib ?

He leído varias respuestas en StackOverflow con respecto a esta pregunta, pero todas apuntan a un libro de más de 300 páginas que necesito leer, mientras que solo quiero un resumen conciso de lo que es importante.

Algunos recursos que ya conozco, pero que no ofrecen un resumen conciso de los conceptos fundamentales para los nuevos usuarios:

• http://railscasts.com/ (bueno, pero fragmentado)
• http://guides.rubyonrails.org/ (supone que ya entiendes las relaciones entre todo)
• http://ruby.railstutorial.org/ (pintar por colores, no hay un buen resumen)
• Rails AntiPatterns (genial, pero debes leerlo todo antes de entender algo)
• The Rails 3 Way (genial, pero de nuevo, tienes que leer todo antes de que entiendas algo)

¡Gracias por cualquier ayuda, referencia u orientación que pueda proporcionar!

PS I would like this wiki to become a living document, so please add to it, edit it, etc. as you feel necessary.

Answer 1

Escribí algunas convenciones de nombres hace un tiempo:

Convenios de rieles

General

Todos los nombres de archivo están en snake_case siguiendo las mismas convenciones - Modelo: singular (por ejemplo, Restaurant ) - Controlador: plural (por ejemplo, RestaurantsController ) - Tabla en DB: plural (por ejemplo, restaurants ) - URL: todo en plural (por ejemplo /restaurants , /restaurants/:id , /restaurants/new )

rails generate Comandos

• Crear modelo: singular (porque el nombre del modelo es singular). por ejemplo, rails g model name:string rating:integer Restaurant name:string rating:integer
• Crear migración: plural (porque usamos el nombre de la tabla). por ejemplo, rails g migration AddDescriptionTo Restaurants description:text
• Crear controlador: plural, por ejemplo, rails g controller index show Restaurants index show

Modelo (singular)

Métodos de ActiveRecord

Todo en singular, porque todos los métodos de ActiveRecord están vinculados al modelo. Ejemplos: - Restaurant.all - Restaurant.create(name: "Burger King", rating: 2) - Restaurant.find(params[:id])

Asociaciones

• Singular en el belongs_to . Porque pertenece a un elemento.
• Plural en el has_many . Porque tiene muchos elementos.

p.ej

class Restaurant < ActiveRecord::Base
  has_many :reviews
end

class Review < ActiveRecord::Base
  belongs_to :restaurant
end

Rutas

Recursos

Plural al definir una ruta para un recurso:

resources :restaurants

Ayudantes de ruta

• index : plural (porque estamos mostrando una lista de elementos). por ejemplo, restaurants_path . También se puede usar para create .
• show : singular (mostramos solo un elemento, necesita el elemento entre paréntesis ). por ejemplo, restaurant_path(@restaurant) . También se puede usar para update y delete .
• new : singular . por ejemplo, new_restaurant_path

Answer 2

1. ¿Cuáles son todas las convenciones de nombres que necesito conocer?

La tabla db es plural, el modelo es singular, el controlador es plural. por lo que tiene el modelo de User respaldado por la tabla de users y visible a través del UsersController .

los archivos deben nombrarse como la versión wide_cased del nombre de la clase. entonces la clase FooBar necesita estar en un archivo llamado foo_bar.rb . Si está creando espacios de nombres con módulos, los espacios de nombres deben estar representados por carpetas. entonces, si hablamos de la clase Foo::Bar , debería estar en foo/bar.rb

2. ¿Cómo deberían estructurarse y nombrarse las acciones del controlador?

las acciones del controlador deben ser RESTful. Eso significa que debe pensar en sus controladores como la exposición de un recurso, no solo como habilitar RPC. Rails tiene un concepto de acciones de miembros frente a acciones de cobranza de recursos. Una acción de miembro es algo que opera en una instancia específica, por ejemplo /users/1/edit sería una acción de miembro de edición para los usuarios. Una acción de cobranza es algo que opera en todos los recursos. So /users/search?name=foo sería una acción de recopilación.

Los tutoriales anteriores describen cómo implementar realmente estas ideas en su archivo de rutas.

3. ¿Cuáles son las mejores formas de presentar información en una vista (a través de :content_for o render a partial) y cuáles son las formas que no debo usar?

content_for debe utilizarse cuando desee agregar html desde una plantilla interna a una plantilla externa; por ejemplo, puede agregar algo de su plantilla de vista a su plantilla de diseño. Un buen ejemplo sería agregar una página javascript específica.

# app/views/layout/application.rb
<html>
  <head>
    <%= yield :head %>
...

# app/views/foobars/index.html.erb

<% content_for :head do %>
  <script type=''text/javascript''>
    alert(''zomg content_for!'');
  </script>
<% end %>

los parciales son para dividir archivos de gran tamaño o para renderizar el mismo bit de información varias veces. Por ejemplo

<table>
  <%= render :partial => ''foo_row'', :collection => @foobars %>
</table>

# _foo_row.html.erb

<tr>
 <td>
  <%= foobar.name %>
 </td>
</tr>

4. ¿Qué debería ir a un ayudante y qué no?

sus plantillas solo deberían tener lógica de bifurcación básica . Si necesita hacer algo más intenso, debería ser un ayudante. las variables locales en las vistas son una abominación contra todo lo que es bueno y justo en el mundo, por lo que es una gran señal de que debes hacer una ayuda.

Otra razón es solo la reutilización del código puro. Si está haciendo lo mismo con solo una pequeña variación una y otra vez, jálelo a un ayudante (si es exactamente lo mismo, debería ser un parcial).

5. ¿Cuáles son las dificultades comunes o algo que necesito hacer correctamente desde el principio?

los parciales nunca deben referirse directamente a variables de instancia (@), ya que evitarán la reutilización en la línea. siempre pase datos a través de :locals => { :var_name => value } param a la función de renderizado.

Mantenga la lógica fuera de sus puntos de vista que no está directamente relacionada con la representación de sus puntos de vista. Si tiene la opción de hacer algo en la vista, y hacerlo en otro lugar, 9 de cada 10 veces, hacerlo en otro lugar es la mejor opción.

Tenemos un mantra en los rieles que es "modelos gordos, controladores delgados". Una razón es que los modelos están orientados a objetos, los controladores son inherentemente procedurales. Otra es que los modelos pueden cruzar controladores, pero los controladores no pueden cruzar modelos. Un tercero es que los modelos son más comprobables. Es solo una buena idea.

6. ¿Cómo puedes modularizar el código? ¿Para eso está la carpeta lib?

la carpeta lib es para código que cruza las preocupaciones de los modelos (es decir, algo que no es un modelo, pero que será utilizado por varios modelos). Cuando necesites poner algo allí, lo sabrás, porque no podrás descubrir en qué modelo ponerlo. Hasta que eso suceda, puedes ignorar lib.

Algo a tener en cuenta es que a partir de los rieles 3, lib no está en la ruta de carga automática, lo que significa que debe require todo lo que coloque allí (o lo vuelva a agregar)

Una forma de requerir automáticamente todos los módulos en el directorio lib :

#config/initializers/requires.rb
Dir[File.join(Rails.root, ''lib'', ''*.rb'')].each do |f|
  require f
end