El 24/02/07, Luis Lavena <[EMAIL PROTECTED]> escribió: > On 2/23/07, Aureliano Calvo <[EMAIL PROTECTED]> wrote: > > Diego, > > Acabo de leer todo el mail que mandaste (sip, es largo). Me parece que con > > esto de REST estamos todos con parálisis analítica. Hasta dónde lo entendí, > > los 2 grandes problemas que tenemos son: > > (1) ¿Qué hago con los controllers que no tienen un Model trivialmente > > asociado? (Ej: página ppal del site, about, manejo de sesiones) > > Tal vez el mail anterior mio paso desapercibido, pero planteaba que > hacer en los casos estos.
Luis, no pasó desapercibido, por lo menos no para mí :-D. > > Por más de no tener un modelo asociado, comprender la sesión del > usuario como un modelo es sencillo. > > (estamos hablando de un single resource (map.resource :session) Si, es cierto. Yo al principio pensaba que todo controller tenía que corresponderse con un modelo. Por lo menos todos los ejemplos que había encontrado en internet eran así. Pero no. El video de Peepcode me confirmó que no y además este mismo ejemplo que onés sobre la sesión es utilizado en el plugin RESTful_authentication. Ese plugin usa 2 resources: Users y Sessions, pero sólo un modelo: User. Otra cosa para notar de tu ejemplo es el uso de Session en singular y no plral. Aclaremos que eso sólo es soportado desde Rails 1.2.2 y no en 1.2.1. Es lo que llaman Singleton Resources y se aplica justamente a cosas como la sesión que son únicas desde el punto de vista del mismo usuario y este nunca manejará una colección de sesiones. Por esto mismo, es que se me ocurrió como válido el tener un controller para manejar el homepage (HomepageController). Pero no sé si lo voy a hacer así. > > Al usuario le es presentada una opción de login (GET session/new) > El formulario de la pantalla de login usara POST session (create) > Para hacer "logout" simplemente tenes que generar un link a session > con DELETE (destroy). Exactamente lo que hacer RESTful_authentication. > > Perfectamente desde el SessionController podes redireccionar al perfil > del usuario, al dashboard o lo que quieras... esto ya depende de vos. > > > (2) ¿Qué hago con los Models que deben ser manipulados de diferentes > > maneras según diferentes tipos de usuario? (ejemplo: posts en un blog, los > > usuarios normales los ven y el administrador necesita CRUD). > > > > Eso sigue dependiendo del ROL del usuario. Creo lo que todos quieren > plantear sobre este tema es hacer una separación de dos layouts... uno > para el usuario normal y otro para el administrador. Sí... pero no. Es más complejo que sólo los layouts. Ese es el ejemplo, para mí demasiado simplista, que se puede ver en el video demo de Peepcode. Si te ponés a pensar, en el layout público vas a necesitás mostrar muchas cosas que deberán cargarse en la acción correspondiente del controller. Pero en el layout administrativo, esos datos extras (como banners, etc) serán irrelevantes, pero es posible que necesites cargar otros datos que no eran necesarios para el layout público. Entonces, cada acción que pueda ser ejecutada tanto desde un sitio como de otro, tendrá que tener un "case" grandote para saber qué variables cargar. o de última tener al menos un if que delegue la responsabilidad a 2 métodos más específicos (index -> index_publico o index_admin). Eso me parece medio feo... bastante feo. Si en todos los métodos voy a tener el mismo if, hay algo mal. El famework debería proveerme de la separación y él mismo llamar a los métodos diferentes. En definitiva, si te ponés a pensar en este enfoque, es lo mismo que hacer 2 controllers separados por namespaces, pero en este caso es un sólo controller con el doble de métodos. Algo tengo que estar razonando mal porque supuestamente con REST tengo que obtener todo locontrario: más controllers, más simples. > > > En el caso (1) las opciones son si hacer un controller tipo REST o normal. > > Y en el caso (2) las opciones son si hacer un solo controller o varios (uno > > x rol x recurso). En ambos casos, las diferencias que quedarían entre un > > tipo de "arquitectura" y la otra no son muchos, así que te voy a sugerir > > algo bastante herético. Ahí ya no coincidimos. Yo creo que la cosa cambia bastante. Hay bastantes cambios y el enfoque es muy diferente. > > > > En vez de preguntarte cuál es mejor, hacelo de alguna de las 2 maneras en > > ambos casos, y hacé que el site ande (x lo menos una parte "productible"). > > Por suspuesto con todos los tests de unidad, funcionales y de integración > > correspondientes ;). Y si no te gusta, cambiá los tests de a uno y los > > controllers de a 1 (con los correspondientes cambios en las views, que solo > > deberían ser los URLs a los controllers) a la otra forma (los models, en > > ppio. deberían quedar iguales, ¿no?). Sí, los modelos no deberían verse afectados, creo yo. > > > > En esto coincido con Aureliano... Simplemente hazlo como creas te > convenga, aún si algunos controladores no son REST friendly, tenés que > pensar que para vos si son friendly hacerlos ;-) Jaja! es cierto. > > Una de las cosas que te recomiendo es si planteas incorporar contenido > casi estático (como el about_us y cosas asi que planteas de tu > HomepageController), optes por Comatose [1] de Matt McCray, es un mini > CMS que sirve precisamente para este tipo de contenido. > > Yo lo estoy usando para la ayuda en linea, los FAQ y un par de > Tutoriales de algunas aplicaciones (seria la ayuda on-line, chiste al > margen) :-) Te diría que el sitio va tener un 95% de contenido dinámico. > > > > Ah! Y después contanos como salió todo (incluyendo qué quedó, y si lo > > cambiaste de la forma original en la que lo hiciste o no y porqué). > > > > Si, esta parte es buena, compartí tus apreciaciones al respecto, ya > que todos podemos beneficiarnos de los comentarios. No hay duda de que lo haré. Pero van a tener que esperar un buen tiempo. Porque recién empiezo. > > > Éxitos y happy coding, > > Aureliano. > > Lo mismo!, Happy Coding! :-) > > I hope so! ;-D Diego _______________________________________________ ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
