On 2/21/07, Diego Algorta Casamayou <[EMAIL PROTECTED]> wrote:
> [...]
>
> 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.
>
Bien, lo que seria importante destacar del concepto REST es "para
quien" expones el recurso.
REST no es solamente simplificar como expones tus recursos (un
modelo->un controlador) sino crear conceptos que pueden vincular
varios modelos.
Por ejemplo:
SessionController (si, en singular). Session en si no representa un
modelo/recurso, pero en si expone cierta funcionalidad que es
necesaria:
session/new, session/delete(o el popular destroy).
La Session, al ser un concepto de una entidad, se convierte en un
recurso que podes manejar.
Así pasa, por ejemplo, con un Bucket (que es uno de mis casos), en
donde no existe un modelo en si en la DB al cual mapear el controlador
(pero si en la session), es una entidad en si misma, y podes exponerla
mediante REST.
> 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 de las cosas que me llamaron la atención de Rails Way [1][2] en su
análisis de SingOut y su "RESTification", es que plantearon
controladores que no mapean directamente con el modelo, pero sirven
para hacer que el modelo se transforme de acuerdo a los
verbos/acciones de HTTP.
> 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...
>
Pensá en REST como una API con la cual vos accederías a tu
applicación... Que utilidad tendría ingresar al homepage desde un
cliente remoting REST?
Lo que te permitiría acceder a la parte administrativa de tus recursos
es una cuestión de Roles y Permisos, y no una cuestión de REST o no
REST.
Así también, los contenidos estáticos (como el About o cosas
similares) que no son parte en si de la aplicación, sino extras,
podrías plantearlos con mini CMS como Comatose CMS [3]
Yo también estoy encarando el concepto de REST y no REST... ya me
siento Hamlet haciéndome esa profunda pregunta. (To REST or not to
REST) ;-)
[1] http://www.therailsway.com/2007/2/13/signout-part-1
[2] http://www.therailsway.com/2007/2/20/signout-part-2
[3] http://comatose.rubyforge.org/
--
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi
_______________________________________________
ruby mailing list
[email protected]
http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
