Primeramente debo decir que la charla viene muy interesante.
Como agregado, y habiendo vivido en el mundo de otros lenguajes antes de
Ruby/RoR, considero que deben mirar un paso mas afuera del que lo están
haciendo.
A quienes se ponen nerviosos ante los posibles flames, les digo que prefiero
muchos intentos de flames antes que no tenerlos, y eso es porque demuestra
que:
1. La comunidad es lo bastante grande para que desde otros ambientes
intentes "robar" adeptos.
2. Demuestra que deberán conseguir mayores y mejores argumentos para
justificar un "pasarse" al lado oscuro.
En el orden de lo discutido de los resources y definidiciones de metodos en
los controllers, sin tener experiencia en sinatra, puedo decir que el manejo
de resources me parece una ventaja muy interesate, para explicarme mejor:
Si tengo un routes.rb donde manejo todas mis rutas, y con la ayuda de "rake
routes" puedo ver como es dicho mapeo e ir corrigiendo las rutas que NO
deseo exponer. Si dejo rutas "abiertas" es mi error, y no del framework.
Desconozco si Sinatra por ejemplo tenga esta posibilidad.
Antes cualquier problema de rutas se que tengo que ir exclusivamente a un
lugar a mirarlo -config/routes.rb- y no mirar en varias definiciones.
Estamos hablando por supuesto de un sistema con un cantidad de rutas lo
bastante grande como para tener que llevar un control de esa medida, no
estamos hablando de un blog de 15 min.
Si yo tengo que generar un comprotamiento de rutas lo suficientemente
completo, el recurso de resources me permite muchas posibilidades de
configuracion en un solo punto, las cuales dejo a continuacion extraidas de
la documentacion:
:collection - Add named routes for other actions that operate on the
collection. Takes a hash of #{action} => #{method}, where method is
:get/:post/:put/:delete, an array of any of the previous, or :any if the
method does not matter. These routes map to a URL like /messages/rss, with a
route of rss_messages_url.
:member - Same as :collection, but for actions that operate on a specific
member.
:new - Same as :collection, but for actions that operate on the new resource
action.
:controller - Specify the controller name for the routes.
:singular - Specify the singular name used in the member routes.
:requirements - Set custom routing parameter requirements; this is a hash of
either
:conditions - Specify custom routing recognition conditions. Resources sets
the :method value for the method-specific routes.
:as - Specify a different resource name to use in the URL path. For example:
:has_one - Specify nested resources, this is a shorthand for mapping
singleton resources beneath the current.
:has_many - Same has :has_one, but for plural resources.
:path_names - Specify different path names for the actions. For example:
:path_prefix - Set a prefix to the routes with required route variables.
:name_prefix - Define a prefix for all generated routes, usually ending in
an underscore. Use this if you have named routes that may clash.
:shallow - If true, paths for nested resources which reference a specific
member (ie. those with an :id parameter) will not use the parent path prefix
or name prefix.
:only and :except - Specify which of the seven default actions should be
routed to.
:only and :except may be set to :all, :none, an action name or a list of
action names. By default, routes are generated for all seven actions.
Todo esto nos permite hacer algo como lo siguiente:
map.resources :posts, :only => [:index, :show] do |post|
post.resources :comments, :except => [:update, :destroy]
end
# --> GET /posts (maps to the PostsController#index action)
# --> POST /posts (fails)
# --> GET /posts/1 (maps to the PostsController#show action)
# --> DELETE /posts/1 (fails)
# --> POST /posts/1/comments (maps to the CommentsController#create
action)
# --> PUT /posts/1/comments/1 (fails)
En 3 lineas defino 7 rutas que me dan el panorama total del manejo de un
resource. Pregunto con total desconocimiento de Sinatra ¿como debo hacerlo
en este otro framework? ¿definiendo uno a uno? ¿puedo ver en un solo lugar
como quedo todo?
Esta es una ventaja que encontré en rails despues de mudarme de otros
lenguajes. Y viendo en muchas aplicaciones desarrolladas con rails, por
ejemplo, se nota que no han leido la documentación para poder explotar a su
mayor beneficio algo tan simple y potente como un resources.
Me parece que muchas veces algunas personas abandonan un framework por algún
detalle que vieron solucionado en otro, sin intentar ver primero como se
soluciona en donde estaban. Tampoco terminan de ver toda la potencia de
donde están. Y por supuesto, muchas veces nos encontramos con el problema de
tener una ferrari (sea cual sea el framework que utilicemos) y solamente
queremos usarla para ir al almacen de la esquina, lo cual nos va a dar
muchisimos problemas, cuando con una bicicleta iriamos mucho mas comodo y
rapido.
En cuanto a tu pregunta Leandro de si estamos pasando a algo offtopic, diria
que no, me parece mas que importante el resaltar que hay que saber mirar a
otros desarrollos, frameworks, experiencia sin tener miedo de una
evangelizacion por parte de otros fanaticos, porque al fin de cuentas todos
los somos, pero si sabemos tomar las soluciones de otros que se enfrentan a
los mismos problemas, podremos asimiliarlas de una manera rapida y sencilla.
Saludos
_______________________
Agustin Viñao
www.agustinvinao.com.ar
agustinvinao (Skype)
2010/1/25 Leandro Marcucci <[email protected]>
> 2010/1/24 Juan Pedro Fisanotti <[email protected]>:
> > El día 23 de enero de 2010 23:35, Federico Brubacher
> > <[email protected]> escribió:
> >> Se q hay gente q se ha cambiado a Merb o Sinatra, mi pregunta es a ellos
> :
> >>
> >> piensan volver a Rails al salir 3.0 ? La verdad q la mayoria de mis
> >> razones en contra de Rails fueron solucionadas con 3.0 .. que piensan?
> >>
> >
> > Creo que mi opinión puede caer medio descolgada, porque dejé Rails
> > cuando me mudé a Python. En Python estoy usando Django, que
> > simplemente me encanta.
> >
> > Pero como aporte al tema, ya que se habla de qué cosas no gustan de
> > Rails, comento lo que yo veo en comparación a Django:
> >
> > - Flexibilidad: uno de los objetivos que Django se propone es el de no
> > "interponerse en el camino del desarrollador". Propone hacer las cosas
> > como el framework las pensó, pero también permite elegir otras formas
> > de hacerlo sin tener que "romper" nada. Es muy sencillo utilizar otro
> > sistema de templates, otro ORM, definir otras estructuras de archivos
> > para la aplicación, etc.
> > A diferencia, Rails obliga mucho a seguir las convenciones que
> > propone, deja poca libertad al desarrollador.
> >
> > - Simplicidad de estructura de una aplicación: algo que me ponía
> > incómodo en Rails era la interminable cantidad de archivos que poseía
> > una aplicación web. En Django es completamente lo contrario. No es lo
> > correcto, pero hasta se podría tener una aplicación con solo 3
> > archivos, de los cuales 1 viene hecho y no sería necesario
> > modificarse.
> > En mi caso esta simplicidad me facilita el desarrollo, ya que no tengo
> > que estar pasando entre infinidad archivos para completar una tarea
> > simple.
> >
> > - Modelos definidos como clases en un solo lugar, con todas las
> > declaraciones de los campos juntas y no repartidas en infinidad de
> > migrations.
> > A quien le gustan las migrations podrá mencionar la ventaja de llevar
> > el historial de los cambios sobre los modelos, y poder sincronizar la
> > base de datos a cualquier momento de ese historial. Bueno, eso mismo
> > es lo que hace cualquier sistema de versionado de código (svn, git,
> > hg), ya que los modelos son en definitiva código, y esto incluye poder
> > sincronizar la base de datos con syncdb, volviéndola a cualquier
> > estado del historial. Así que no veo necesidad de que el framework
> > haga versionado de ese código cuando ya tengo algo que lo hace y me
> > permite además sincronizar la base de datos, y menos cuando ello
> > implica dificultad para conocer el estado actual de los modelos y
> > modificarlo.
> >
> > No vi mucho de Rails 3 (solo la noticia y uno que otro comentario),
> > así que puede que alguna de estas cosas haya cambiado. Ustedes me
> > corregirán.
> >
> > --
>
> Medio que se armo polémica por este email. Está un poquito off topic no?
>
> --
> Leandro Marcucci.
> http://twitter.com/leanucci
> _______________________________________________
> Ruby mailing list
> [email protected]
> http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
>
_______________________________________________
Ruby mailing list
[email protected]
http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
