Habria que ver el caso de uso. Hay cosas en que usaria REST y cosas que no.
Esto me gusto para REST: http://lukeredpath.co.uk/2007/2/2/refactoring-rest-searching-for-an-abstraction Saluti si, no se poner acentos en la mac :-P On 2/21/07, nelson fernandez <[EMAIL PROTECTED]> wrote:
Diego, On 2/21/07, Diego Algorta Casamayou <[EMAIL PROTECTED]> wrote: > > He visto muchos posts, artículos y el keynote de DHH en la RailsConf > sobre REST y resources pero sigo teniendo algunas preguntas sobre el > tema. Yo también estoy jugando con hacer una aplicación REST y me estoy encontrando justamente con estos mismos problemas ;) > No tengo problemas en mapear algunos conceptos a recursos como los > clásicos artículos, anuncios, personas, eventos, etc... Pero no > encuentro una respuesta "REST" para algunos aspectos de una aplicación > web, como por ejemplo un "homepage" que muestra un resumen de los > últimos artículos, anuncios y eventos en el sitio. No se trata de 1 > recurso ni de una colección de recursos del mismo tipo, se trata de un > conjunto de recursos diferentes. > > ¿Cuál sería la forma "REST" de encarar este tipo de funcionalidad? por lo poco que vi hasta ahora.. justamente por 'funcionalidad' ..... uno de los temas de REST es que vas a tener mas controladores que el método anterior, pero con menos código y mas especializados > Obviamente me perdí de algo o todavía no he logrado darme cuenta. si lo llegás a encontrar avisame ! > Otros ejemplos que vienen a mi cabeza: un dashboard (algo como un > panel de control central), páginas de "acerca de este sitio", etc... estos temas por ahora los estoy manejando creado un controlador específico, digamos DashboardController o CompanyController para después mostrar /company/about ... la diferencia es que no utilizo " map.resource :company" ya que eso te crea named routes que no voy a usar, sino que creo las named routes a mano luego para un controlador normal, digamos map.about 'about', :controller => 'company', :action => 'about' > Una pregunta relacionada es cómo manejar los datos relacionados al > "layout". Si tengo un sidebar en mi layout que necesita alimentarse de > ciertos datos en cada request, probablemente lo normal sería usar un > before_filter a nivel del ApplicationController. ¿Ese tipo de > funcionalidad en el controlador (hacer cosas más allá de lo referente > al recurso específico que maneja) es considerada "limpia" al pensar en > funcionalidades tipo REST? no me gusta la solución de los filtros, para una aplicación chica puede andar, pero si usas un dashboard o una página tipo 'portal' se puede ensuciar mucho el controlador. hasta ahora encontré 2 soluciones a este tema: una es utilizar un Sidebar [1], que en mi casi viene perfecto, no es perfecto, pero se acerca mucho.... la otra solución es otro plugin llamado Cells [2], este no lo probé pero lo tengo agendado para mirarlo, es más complejo pero mas versátil también. hasta ahora no encotré tampoco nada que hable sobre como utilizar páginas con REST que no están relacionadas a un modelo. un ejemplo interesante a mirar es el que están desarrollando en The Rails Way [3] (analizan aplicaciones y dan sus opiniones 2 rails core developers) en este momento, donde están desarmando una aplicación del modelo 'tradicional' y pasándola a REST. con respecto al siguiente mail, en que hablás de que según el tipo de usuario querés mostrar una vista con otros datos, eso está más asociado al 'rol' del usuario... personalmente jugaría con eso.. si el rol es de 'admin' le mostras algunos datos y si es usuario común otros, pero el controlador->action es el mismo... sería algo así como lo que hace RoR con el content-type... html, js, xml, etc.... pero utilizando el rol del usuario conectado. [1] http://www.agilewebdevelopment.com/plugins/simple_sidebar [2] http://nick.smt.de/trac/nick/wiki/Cells [3] http://www.therailsway.com/ -- :: nelson :: artesano de software http://netflux.com.ar _______________________________________________ ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
-- Pedro Visintin . I T S o l u t i o n s A r c h i t e c t Ruby On Rails Argentina. http://blogs.onrails.com.ar
_______________________________________________ ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
