Contenido del curso
Entorno de desarollo
Nuestra primera aplicación
- 6

Arquitectura MVC y Flujo de Peticiones en Rails
07:22 min - 7

Creación y Configuración de Aplicaciones Web con Ruby on Rails
11:17 min - 8

Creación de Rutas y Controladores en Ruby on Rails
10:15 min - 9

Creación de Modelos y Migraciones en Ruby on Rails
13:12 min - 10

Gestión de Credenciales Seguras en Ruby on Rails
11:57 min - 11

Gestión de Assets y Layouts en Rails: Asset Pipeline y Webpacker
12:30 min - 12

Uso del Generador Scaffold en Ruby on Rails
10:50 min - 13

Migraciones y Consistencia de Modelos en Rails
05:57 min - 14

Migración de Plantillas ERB a Haml en Ruby on Rails
08:46 min - 15

Creación de Formularios Dinámicos con SimpleForm y Haml en Rails
12:19 min - 16

Internacionalización de Aplicaciones Rails con i18n y i18n-tasks
09:29 min - 17

Debugging en Ruby on Rails: Uso de Bybug y Pry
09:03 min
Proyecto del curso: primeros pasos
- 18

Desarrollo de un Sistema de Gestión de Tareas con Ruby on Rails
05:35 min - 19

Diseño de Modelos de Datos para un Organizador de Tareas
05:45 min - 20

Creación de Scaffolds y Modelos en Rails con SimpleFrame y Bootstrap
10:08 min - 21

Internacionalización de Formularios en Rails con i18n y SimpleForm
11:03 min - 22

Validaciones de Modelos en Ruby on Rails
10:42 min
Proyecto del curso: usuarios
- 23

Autenticación de Usuarios con Devise en Rails
11:42 min - 24

Migración de Llave Foránea: Enlazar Tarea con Usuario en Rails
05:46 min - 25

Integración Visual y Estructural en Rails: Usuario, Tarea y Participante
Viendo ahora - 26

Manejo de Formularios Anidados con Cocoon en Rails
12:25 min - 27

Formularios Dinámicos en Rails con Cocoon y Validaciones de Unicidad
09:36 min - 28

Permisos y Accesos con KanKan en Aplicaciones Rails
14:13 min
Proyecto del curso: interacciones
- 29

Callbacks en Controladores y Modelos en Rails
08:58 min - 30

Automatización de Inserción de Datos en Rails con db:seed
07:38 min - 31

Envío de Correos con ActionMailer en Rails
13:25 min - 32

Creación de notas dinámicas en tareas con Ruby on Rails
17:08 min - 33

Inserciones Dinámicas de Notas con AJAX y SJR en Rails
09:12 min - 34

Mejora de Interfaces con Bootstrap en Aplicaciones Rails
16:19 min
Cierre
Integración Visual y Estructural en Rails: Usuario, Tarea y Participante
Resumen
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:referencesytask:referencescrean 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 :tasksque 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
Participantasociados a la tarea. - Para acceder a los usuarios participantes se usa through, pero como el nombre
participantsno coincide con el modeloUser, 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_userspara 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.