En Peepcode, que hacen documentción paga para Rails, hicieron un screencast de REST.
En la demo muestran una solución piola y REST para el tema de admin. Fijate a ver que te parece. http://topfunky.com/clients/peepcode/REST-preview.mov Saludos, Diego On Feb 21, 2007, at 2:33 PM, Diego Algorta Casamayou wrote: > El 21/02/07, Manuel Aristarán <[EMAIL PROTECTED]> escribió: >> On 2/21/07, Diego Algorta Casamayou <[EMAIL PROTECTED]> wrote: >>> [...] >>> 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? >>> >> >> Todavía no escribí ninguna aplicación completamente RESTiana, así que >> no tengo experiencia 'directa' en el tema. >> En mi opinión, para casos como esos, podés pensar en un enfoque >> híbrido. REST o no, la aplicación sigue siendo Rails y podés crear >> tus >> propias acciones y rutas arbitrarias hacia ellas. >> >> Hace unos días imprimí y leí un muy buen documento introductorio a >> REST en Rails: RESTful Rails Development [1] > > Jeje. Ayer Luis Lavena me pasó el link a ese PDF y me devoré sus > treinta y pico páginas. Estaba rico. Muy bueno y aconsejable. > > Pero igual no me ayudó con esto. No le encuentro bien la vuelta. > > Viendo alguna respuesta que me han tirado en rubyonrails-talk, una > posibilidad es ver esas páginas que son conjuntos de varios recursos > como un recurso en sí mismo. O sea, puedo tener un HomepageController > sólo con la acción index que retorna el recurso (de sólo lectura) > "homepage". Este recurso incluye conjuntos de otros recursos como una > selección de artículos, eventos y otras yerbas interesantes para > incluir en el home. Lo más "raro" de este enfoque es que todos los > ejemplos que he visto de REST y resources siempre mapean un controller > con un modelo. Y en este caso del HomepageController no existe un > modelo Homepage. Por eso no me termina de convencer. > > Otro problema al que me enfrento es el de las diferentes "vistas" a > los mismos recursos. Si pongo "/articles" gracias a "map.resources > :articles" se ejecutará el método index del controller articles. Y eso > me dará una página donde se listarán todos los artículos con sus > resúmenes para que el usuario pueda leerlos. Pero si yo soy el > administrador y pongo "/articles" lo que quiero es que me aparezca una > pantalla de administración donde aparezcan sólo los títulos de los > artículos y cada uno de ellos con botones para editarlos y borrarlos. > ¿Me explico? Si sigo el paradigma REST, la url debe ser la misma en > los dos casos porque el recurso que quiero manejar (la colección de > artículos) es el mismo en los dos casos, pero el contexto o aspecto en > que lo quiero es diferente en cada caso. > > Una posible solución que se me ocurre al vuelo (y no me gusta mucho, > pero puede que esté bien) es agregar un método específico para este > caso: > > map.resources :articles, :collection => {:admin => :get} > # Eso me habilita la url "/articles;admin" > > ArticlesController < ActiveController > def admin > @articles = ... > end > end > > Entonces si quiero leer los artículos, uso "/articles" y si quiero > administrar los artículos uso "/articles;admin" > > Pero no me convence... > > Gracias por los comentarios. > Diego > _______________________________________________ > ruby mailing list > [email protected] > http://lista.rubyargentina.com.ar/listinfo.cgi/ruby- > rubyargentina.com.ar _______________________________________________ ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
