2010/1/24 Leandro Marcucci <[email protected]>: > 2010/1/24 Michel Martens <[email protected]>: >> 2010/1/24 Federico Brubacher <[email protected]>: >>> Michel creo q ahi entramos en un tema de gustos : >>> hay mucha gente creo (aunque no es 100% mi caso ni cerca, es mas cada >>> vez me gusta mas ruby y menos las dsl) que le gustan las DSL locas y >>> la magia de ActiveSupport y no se cuantas cosas mas. >>> >>> Creo que Rails 3 esta prolijo, si bien obviamente viene con "batteries >>> included" para hacer la transicion de los usuarios de 2.3 mas facil, >>> uno puede por ejemplo : elegir que partes de ActiveSupport usar, que >>> partes de ActionController usar, el router esta mejorado (cada ruta es >>> un rack endpoint y solo dsp de q pasa por Rack Realities creo se fija >>> como le "pega" a un controlador. En fin son varias razones por la cual >>> Rails 3 esta mejor . >> >> Lo de las DLSs supérfluas está ejemplificado acá: >> http://blog.citrusbyte.com/2009/12/15/superfluous-dsls/ >> >> Con mapeo innecesario me refiero más que nada a las RESTful routes. Es >> posible crear un website RESTful con Rails, Sinatra, PHP, Java, HTML >> pelado, siempre y cuando se honren las convenciones REST. Con esto >> quiero decir que no hace falta poner map.resources :photos o resources >> :photos, hay otras maneras. >> >> En Rails 3: >> resources :posts >> >> Esto genera las siguientes rutas: >> >> # GET /photos >> def index; ... end >> >> # GET /photos/new >> def new; ... end >> >> # POST /photos >> def create; ... end >> >> # GET /photos/1 >> def show; ... end >> >> # GET /photos/1/edit >> def edit; ... end >> >> # PUT /photos/1 >> def update; ... end >> >> # DELETE /photos/1 >> def destroy; ... end >> >> Si sólo se quiere exponer GET /photos/1, hay que poner map.resources >> :photos, :only => :show. >> >> El gusto por las DSLs puede ser legítimo. Lo que es dudoso es el gusto >> por las DSLs innecesarias. En este caso, el "resources" de Rails está >> generando código para mapear URLs a métodos en un controller, cuando >> Sinatra demostró que es un paso innecesario. La mera existencia del >> comentario antes de cada método --cada "action"-- es indicador de que >> la abstracción es, como mínimo, imperfecta. El efecto colateral de que >> olvidar un :only o un :except implique que un website exponga deletes >> y updates de forma insegura, es indicador de una leaky abstraction. > > Estoy de acuerdo con el argumento, no con la conclusion. No me parece > una abstracion defectuosa. Si usas mal el framework, seguramente el > resultado sera desagradable.
Te invito a justificar esa abstracción. Tratá de demostrar por qué ese mapeo es relevante. >> >> El equivalente con Sinatra: >> >> get "/photos" do ... end >> get "/photos/new" do ... end >> post "/photos" do ... end >> get "/photos/:id" do ... end >> get "/photos/:id/edit" do ... end >> put "/photos/:id" do ... end >> delete "/photos/:id" do ... end >> >> En primer lugar, el comentario cuasi imprescindible de Rails es ahora >> irrelevante. > > ¿? Rails inserta este comentario: # GET /photos :id Digo que al usar Sinatra, no hace falta generar ese comentario porque la definición del entry point es más que explícita: get "/photos/:id" > >> En segundo lugar, la posibilidad de exponer por accidente >> algún método es casi inexistente. > > Claro, no podes exponer nada que no escribiste. Con rails no necesitas > escribirlo, y la mayoria de las veces vas a querer exponerlo, he aqui > la ventaja de lo que ofrece Rails. (ojo, una cosa es una cosa y otra > cosa es otra cosa: el resultado bueno a cualquier precio no es > correcto, podria estar bien hecho). No veo la ventaja. Hablás del generador de código? Supongamos el caso de DELETE /photos/:id Con Sinatra: delete "/photos/:id" do ... end Con Rails: resources :photos def destroy; ... end En la versión de Rails hay más código, no? El hecho de que no necesites escribirlo por haberlo generado con un scaffold creo que es irrelevante, porque hay generadores de código para cualquier framework. Cuando hablaba de métodos expuestos por error me refería a lo siguiente: supongamos que tenés un método def edit; ... end, con su correspondiente vista. Al borrar el método del controller, la vista sigue siendo accesible. >> En tercer lugar, la cantidad de >> memoria y ciclos de CPU es ridículamente menor. > > En C es mucho menor que en ruby, habria que hacer sitios web en C. Es en serio este comentario? > >> En cuarto, la cantidad >> de ciclos cerebrales (para seguirle la corriente al mapeo de Rails) es >> reducida a cero. > > Siempre me molesto muchisimo lo dificil de seguir que es el trace de > cualquier cosa que haga rails. + 1 a la no simplicidad. > >> Si lo que Rails ofrece es un atajo para generar >> websites restful, por qué razón con Sinatra obtengo un mejor resultado >> tipeando menos? > > El resultado no es necesariamente mejor siempre, ni peor siempre. > Tampoco estas tipeando menos. Es mas, estas tipeando de mas. Salvo que > quieras programar REST mal, siempre vas a tener el mismo verbo http > antes de la misma accion/ruta. Estas tipeando --muchisimas-- mas cosas > obvias que el comentario de rails, que solo es escrito por el > generador de scaffold (dejo lugar a que en rails 3 estos comentarios > sean necesarios, pero lo dudo mucho). De nuevo creo que estás confundiendo cantidad de código con quién lo genera. No importa que lo generes con un scaffold, porque lo mismo aplica para cualquier framework. Lo importante es que hay mayor cantidad de código en la versión de Rails que en la de Sinatra. >> >> En Rails 3 es más sencillo integrar middlewares de Rack. Incluso es >> sencillo integrar aplicaciones de Sinatra como midlewares de Rack. >> Para qué me tomaría el trabajo de armar algo con Rails, incurrir en >> los costos (mentales y otros) que describí, para poder "bajar" a >> "metal" e insertar aplicaciones de Sinatra, cuando puedo escribirlas >> directamente y obtener algo mejor, que ocupa una fracción del RAM y se >> ejecuta mucho más rápido? Cuál es la ganancia? >> >> Saludos, >> >> -- >> Michel >> _______________________________________________ >> Ruby mailing list >> [email protected] >> http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar >> > > Como dicen por ahi, la mejor herramienta para cada caso. Rails es una > buena herramienta para desarrollar sitios web seguros, con codigo > elegante corriendo "sobre" él, así como lo es Sinatra, y cualquier > otro. Simplemente cada uno sirve para solucionar problemas diferentes. No lo veo así, creo que ambas herramientas apuntan a solucionar el mismo problema. Por qué creés que sirven para solucionar problemas diferentes? -- Michel _______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
