On Jan 3, 2008 9:10 AM, Andres Quijano <[EMAIL PROTECTED]> wrote: > On Jan 3, 2008 9:08 AM, Michel Martens <[EMAIL PROTECTED]> wrote: > > Creo que Rails fue una buena idea hace cuatro años, una buena > > aproximación a un framework MVC hecho en Ruby. Por lo demás, el diseño > > deja mucho que desear y está plagado de errores conceptuales. > > como cuales? >
De movida, el hecho de analizar el path de un request_uri utilizando separadores y luego expresiones regulares parece redundante. Por ejemplo: /foo/:bar Si quieren obtener :bar, alcanza con una expresión regular. No hace falta tomar por separado foo, bar y luego examinar por separado cada token. Eso sin considerar las vueltas que da Rails a partir de ese momento, que por supuesto ya fue superado por Merb y sus lambdas. Para cerrar con el tema rutas, es triste que el hecho de utilizar separadores no permita rutas de este estilo: Si se usaran expresiones regulares sin separadores, sería posible armar rutas de este estilo: /foo/list_by_:criteria (que permitiría list_by_zone, list_by_price, etc.). Otro error de Rails es haber pretendido integrar REST con el esquema original de :controller/:action/:id. Hay cuatro verbos HTTP, hay cuatro operaciones CRUD. Con qué aritmética se obtienen 7 (siete) métodos básicos en un controlador REST. La respuesta es que Rails integró el paradigma REST sin quebrar la compatibilidad con el paradigma anterior de :controller/:action/:id. El hecho de que en el esquema :controller/:action/:id el :id sea opcional hace que el mismo controlador se tenga que encargar de un conjunto de recursos y de cada recurso en particular. Un GET a /properties muestra un listado de propiedades, correcto. Un POST a /properties crea una nueva propiedad, de acuerdo. Un POST a /properties/1, qué hace? Para ilustrar, acá van los mapeos de Rails: GET / collection => index GET / member => show GET / member new form => new GET / member edit form => edit POST / collection => create POST / member (PUT) => update POST / member (DELETE) => destroy Ahora pregunto: por qué Rails necesita los métodos PUT y DELETE? Una posibilidad es que el paper original de Fielding que define REST hable de GET, POST, PUT y DELETE... Yo no pude encontrarlo en http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_3, así que si alguien lo tiene y quiere compartirlo, adelante. Lo que me resulta gracioso es que los browsers no soportan los métodos PUT y DELETE y, como Rails los necesita, la comunidad Rails concluyó que los browsers están equivocados. HTTP define los métodos OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT. Para REST, los únicos que se necesitan son GET y POST. Va un ejemplo: GET /properties #=> listado de propiedades POST /properties #=> crea una nueva propiedad GET /properties/1 #=> muestra la propiedad 1 POST /properties/1 #=> modifica la propiedad 1. Es sencillo entender que PUT es supérfluo. Para DELETE, hace falta una explicación extra: hablando en términos Railísticos, cuando uno actualiza un recurso lo que hace es enviar el hash params[:property] al modelo, quien se encarga de hacer la actualización correspondiente. Si uno intenta esto: @property.update_attributes(nil), lo que ocurre es que el modelo queda intacto. <historia_ilustrativa> Si yo les pido que en donde está el pino pongan un jacarandá, todos me van a entender. Si luego les pido que en donde está el jacarandá pongan un abeto, también. Si por último les pido que en donde está el abeto pongan _nada_, eliminan el abeto o sigue en pie como si nada hubiera pasado? </historia_ilustrativa> Según Rails, el abeto sigue en pie. Si removiera el abeto en vez de ignorar la orden, entonces @property.update_attributes(params[:property]) sería equivalente a @property.destroy, y ya no necesitaríamos _method="DELETE" o hacks semejantes. Pueden no estar de acuerdo con este razonamiento, pero en todo caso les garantizo que este esquema funciona porque ya lo probé. En fin, se hizo muy largo este mail. Hay otros defectos, como el thread safety que menciona Zed, el hecho de ser controller-oriented (como Merb) en vez de routes-oriented, como Sinatra (http://sinatra.rubyforge.org/), y en general todas las decisiones derivadas de mantener la compatibilidad con el (arcaico?) :controller/:action/:id. Saludos, -- Michel _______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
