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, -- Michel _______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
