Hola muchachos! Tienen un ejemplo de options_from_collection_for_select.
Gracias. ________________________________ De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de Pedro Visintin Enviado el: jueves, 22 de febrero de 2007 14:57 Para: Grupo Ruby Argentina Asunto: Re: [Ruby Arg] Preocupaciones para comenzar un nuevo sitio "a laREST" Insisto, es importante el analisis de los casos de uso, eso te va a indicar si te suma o no el exponer algunos o todos los recursos con REST o no. Usar REST o no, es una decision funcional. Sin duda REST tiene un papel importantisimo en la integración de aplicaciones web. Saluti P On 2/22/07, Luis Lavena <[EMAIL PROTECTED]> wrote: 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 -- 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
