Integración Visual y Estructural en Rails: Usuario, Tarea y Participante

Contenido del curso

Introducción

Entorno de desarollo

Nuestra primera aplicación

Proyecto del curso: primeros pasos

Proyecto del curso: usuarios

Proyecto del curso: interacciones

Cierre

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:009:53

Integración Visual y Estructural en Rails: Usuario, Tarea y Participante

Curso de Introducción a Ruby on Rails

Clase 25 de 36

Clase 25 / 36

Recursos

Construir relaciones complejas entre modelos es una de las habilidades fundamentales para desarrollar aplicaciones robustas con Ruby on Rails. Aquí se aborda cómo resolver el error de validación al crear tareas, cómo generar un modelo intermedio de participante y cómo configurar asociaciones avanzadas con has_many, belongs_to y through.

¿Cómo resolver el error de validación al crear una tarea?

Al intentar crear una tarea desde el formulario, aparece un error de validación invisible relacionado con la relación belongs_to :owner definida en el modelo Task [01:07]. En Rails, las relaciones belongs_to incluyen por defecto una validación de presencia, lo que significa que no es posible guardar el registro sin que ese campo esté asociado a un objeto válido.

La solución consiste en asignar el owner directamente en el controlador, ya que este dato no proviene del formulario sino de la sesión activa del usuario. En el archivo app/controllers/tasks_controller.rb, dentro de la acción create, se añade la línea:

ruby @task.owner = current_user

El método current_user es proporcionado por la gema Devise [02:24]. Este método devuelve la referencia al usuario que ha iniciado sesión y está disponible tanto en controladores como en vistas. Al colocar esta asignación antes de la línea donde se ejecuta el save, Rails incluirá automáticamente la relación al momento de guardar el registro.

¿Cómo generar el modelo participante como tabla intermedia?

El modelo Participant actúa como una tabla intermedia entre User y Task [03:05]. Se genera desde la consola con:

bash rails generate model Participant role:string user:references task:references

El atributo role identifica la función del participante dentro de la tarea.
Las directivas user:references y task:references crean automáticamente las relaciones belongs_to en el modelo y las claves foráneas en la migración [03:30].

Al revisar el archivo de migración en db/migrate/create_participants, se confirman los atributos y las referencias correctamente generadas.

¿Cómo configurar las asociaciones avanzadas en los modelos?

Esta es la parte más rica en detalle. Cada modelo requiere configuraciones específicas para que las relaciones sean semánticamente claras y funcionales.

¿Qué relaciones se definen en el modelo User?

Dentro de app/models/user.rb se agregan dos asociaciones importantes [04:15]:

ruby has_many :participations, class_name: "Participant" has_many :tasks, through: :participations

Se usa el nombre participations en lugar de participants porque describe mejor lo que el usuario tiene: participaciones en tareas.
Como el nombre no coincide con el modelo, se especifica class_name: "Participant" para indicar a Rails cuál es la clase asociada.
La directiva through: :participations permite acceder directamente a las tareas en las que el usuario participa, sin pasar manualmente por la tabla intermedia [05:22].
La relación previa has_many :tasks que representaba las tareas propias se renombra a owned_tasks para evitar conflictos de nombres [05:55].

¿Qué relaciones se definen en el modelo Task?

En app/models/task.rb se aplica un esquema similar pero con una particularidad adicional [06:15]:

ruby has_many :participating_users, class_name: "Participant" has_many :participants, through: :participating_users, source: :user validates :participating_users, presence: true

participating_users agrupa los registros de la tabla Participant asociados a la tarea.
Para acceder a los usuarios participantes se usa through, pero como el nombre participants no coincide con el modelo User, se añade la clave source: :user [07:32]. Este atributo indica a Rails cuál es la fuente real de datos en la relación.
Se agrega una validación de presencia sobre participating_users para garantizar que toda tarea tenga al menos un participante asignado [08:05].

Es relevante notar la diferencia entre class_name y source: el primero se usa en relaciones directas has_many para indicar el modelo, mientras que el segundo se usa en relaciones through para especificar el origen de los datos.

Con los tres modelos completamente relacionados, el siguiente paso natural es llevar estas asociaciones a la interfaz visual mediante formularios anidados, un concepto clave en el desarrollo web con Rails que permite gestionar múltiples modelos desde un solo formulario.

¿Has trabajado con relaciones many-to-many usando through en tus proyectos? Comparte tu experiencia y las dificultades que encontraste.

David Campos

Hace 5 años

Si tratamos de agregar una tarea desde el navegador nos lanzará un error aunque todos los campos estén validados, esto es por la relación que se hizo la clase pasada (belongs_to :owner). Las relaciones con belongs_to no pueden quedar vacías.

Para solucionar el problema hay que relacionar el usuario que inició sesión con la tarea pero de manera interna.

El mejor lugar para hacer esta asociación es el controlador tasks_controller.rb, y en el método create del mismo.

Para hacerlo se usa la variable de instancia task que ya existe en el controlador, y se le asigna a su propiedad owner el usuario actual con la variable de entorno current_user. El método current_user es provisto por devise y devuelve la referencia del usuario que inició sesión.

Participant

Creación del modelo Participant: rails g model Participant role:integer user:references task:references.

Una vez creado el modelo hay que especificar como serán las relaciones con user y task.

En el archivo User.rb agregamos: has_many :participations,class_name: 'Participant', pero debido a que esta es una relación intermedia para una asociación de muchos a muchos se puede llegar a las tareas en las cuales el usuario está participando a través del otro método.

has_many :owned_tasks
has_many :participations, class_name: 'Participant'
has_many :tasks, through: :participations

Este nuevo método representa una variación de has_many, la consigna sería que un usuario tiene muchas tareas, pero estas tareas no son las tareas directas, sino a las que se accede a través de participations. El método es: has_many :tasks, through: :participations.

Ahora hay que aplicar este mismo concepto con las tareas. En este caso se podría decir que las tareas tienen muchos participantes (usuarios).

has_many :participating_users, class_name: 'Participant'
has_many :participants, through: :participating_users, source: :user

Algo que se agregó fue la propiedad source, esto porque se utilizo participants en el has_many y no users, entonce hay que especificar que se trata de el modelo user.

Por último hay que validar que una tarea siempre tenga participantes, esto dentro del model Task:

validates :participating_users, presence: true

Comentarios (10)10 comentarios

José Gersain Osorio Morales

Hace 6 años

Johan Tique

Profesor

Jose Ramos

Anibal Español

Manuel Alejandro González Cabello

Jesús Miguel Quinto Teran

Daniel J. Pérez

Hace 4 años

Jesus Eduardo Cervantes Hernandez

Fernando Mejia Laguna

Hace 2 años

Javier Omar Pacheco

Fabián Andrés Arismendi Ferrada

Introducción

Curso Completo de Ruby on Rails: Introducción y Proyecto Práctico

Historia y Evolución de Ruby y Ruby on Rails

Entorno de desarollo

Módulos Esenciales de Ruby on Rails

Instalación de Ruby on Rails en Ubuntu 20.04 LTS

Instalación de Ruby on Rails en macOS y Windows 10

Nuestra primera aplicación

Arquitectura MVC y Flujo de Peticiones en Rails

Creación y Configuración de Aplicaciones Web con Ruby on Rails

Creación de Rutas y Controladores en Ruby on Rails

Creación de Modelos y Migraciones en Ruby on Rails

Gestión de Credenciales Seguras en Ruby on Rails

Gestión de Assets y Layouts en Rails: Asset Pipeline y Webpacker

Uso del Generador Scaffold en Ruby on Rails

Migraciones y Consistencia de Modelos en Rails

Migración de Plantillas ERB a Haml en Ruby on Rails

Creación de Formularios Dinámicos con SimpleForm y Haml en Rails

Internacionalización de Aplicaciones Rails con i18n y i18n-tasks

Debugging en Ruby on Rails: Uso de Bybug y Pry

Proyecto del curso: primeros pasos

Desarrollo de un Sistema de Gestión de Tareas con Ruby on Rails

Diseño de Modelos de Datos para un Organizador de Tareas

Creación de Scaffolds y Modelos en Rails con SimpleFrame y Bootstrap

Internacionalización de Formularios en Rails con i18n y SimpleForm

Validaciones de Modelos en Ruby on Rails

Proyecto del curso: usuarios

Autenticación de Usuarios con Devise en Rails

Migración de Llave Foránea: Enlazar Tarea con Usuario en Rails

Integración Visual y Estructural en Rails: Usuario, Tarea y Participante

Manejo de Formularios Anidados con Cocoon en Rails

Formularios Dinámicos en Rails con Cocoon y Validaciones de Unicidad

Permisos y Accesos con KanKan en Aplicaciones Rails

Proyecto del curso: interacciones

Callbacks en Controladores y Modelos en Rails

Automatización de Inserción de Datos en Rails con db:seed

Envío de Correos con ActionMailer en Rails

Creación de notas dinámicas en tareas con Ruby on Rails

Inserciones Dinámicas de Notas con AJAX y SJR en Rails

Mejora de Interfaces con Bootstrap en Aplicaciones Rails

Cierre

Despliegue de Aplicaciones en Heroku con Ruby on Rails

Desarrollo de Aplicaciones Web con Ruby on Rails

Integración Visual y Estructural en Rails: Usuario, Tarea y Participante