El día 24 de enero de 2010 12:45, Michel Martens <[email protected]> escribió: > 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. > > 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. En segundo lugar, la posibilidad de exponer por accidente > algún método es casi inexistente. En tercer lugar, la cantidad de > memoria y ciclos de CPU es ridículamente menor. En cuarto, la cantidad > de ciclos cerebrales (para seguirle la corriente al mapeo de Rails) es > reducida a cero. Si lo que Rails ofrece es un atajo para generar > websites restful, por qué razón con Sinatra obtengo un mejor resultado > tipeando menos? > > 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, > Mi opinion es que rails se volvio un gigante, tiene muchas cosas que nunca voy a usar.
ahora uso este que es modular y me permite mayor libertad de eleccion. http://ramaze.net/ salu -- --Gabriel Máculus-- _______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
