ruby on rails - modal - ¿Deberían los rails llamadas ajax incluirse en su propio controlador por separado?
javascript en ruby on rails (2)
En caso de que las llamadas AJAX que no son RESTful sean:
- poner en el controlador que más se adapte a su funcionalidad / vista, o
- agrupados en su propio controlador ''Ajax'' por separado?
He estado haciendo 1, pero acabo de leer este artículo (2725 diggs)
http://zygote.egg-co.com/10-dirty-little-web-development-tricks/ (ver el punto 9)
y este muchacho opta por el método 2. Pero él es un desarrollador de PHP.
Un beneficio podría ser que 2 podría limpiar las rutas haciendo algo como ''ajax /: acción'' en lugar de agregar miembros a rutas tranquilas.
Parece un 6.5 de una, media docena de panadero del otro tipo de cosas.
¿A qué opción vas?
Prefiero el primer acercamiento:
- es semánticamente consistente. si una acción de Ajax involucra el recurso XXX, usted (y otros programadores) sabrán dónde encontrar cosas en su aplicación, gracias a las convenciones de Rails.
- si su aplicación es pesada en Ajax (y en la actualidad la mayoría lo son), terminará con un gigantesco AjaxController que niega todo lo RESTful. El resto de sus controladores estarán allí solo para proporcionar acciones CRUD que no sean javascript graciosamente degradadas.
- Del mismo modo, probar tu controlador Ajax tenderá a ser un poco desordenado porque tendrás que configurar escenarios - cargar accesorios, simulacros, etc. para cada recurso "ajaxificado" de tu aplicación.
Sus controladores "RESTful" probablemente incluyan acciones new y de edit , ninguna de las cuales es RESTful, solo proporcionan interfaces de usuario para create y update acciones de REST. new y edit no reciben NonRestUIController por separado o algo así, se mantienen en el controlador de sus recursos asociados, manteniendo sus controladores semánticamente consistentes. De forma similar, las acciones de Ajax que se relacionan con un cierto conjunto de funcionalidades o un determinado recurso deben permanecer en el controlador asociado.