DRY en administración

Si en el controlador tengo una clase madre de la que heredan todas las
clases que se ocupan de cada modelo, puedo compartir los metodos
edit,show,create …? De tal forma que lo único que me quedaria
particular en cada caso seria el formulario donde meto los datos.

No domino mucho de rails y no se como pasarle los parametros a los
metodos y como deberia hacer el método general para cada caso

Algún consejo?

Gracias

Jaume wrote:

Gracias

El único consejo que te puedo dar es que te expliques mejor porque no se
te entiende nada. Mejor di que quieres lograr. Toma en cuenta que Rails
es la implementación del patrón MVC para aplicaciones Web. No es una
herramienta de propósito general. Antes de usar Rails debes de evaluar
si se aplica a tu app.

Tengo que desarrollar una aplicación en Ruby on Rails, y me gustaría
disponer de manuales tanto para Ruby como para Rails. Ya os digo de
antemano que no tengo ni idea, y me gustaría empezar poco a poco.

Esteban wrote:

El único consejo que te puedo dar es que te expliques mejor porque no se
te entiende nada. Mejor di que quieres lograr. Toma en cuenta que Rails
es la implementación del patrón MVC para aplicaciones Web. No es una
herramienta de propósito general. Antes de usar Rails debes de evaluar
si se aplica a tu app.

Perdón por mi mala explicación.

Quiero hacer una aplicación típica web con gestión de contenidos de lo
más sencilla para jugar. Creo que si me sirve rails para esto.

Total. Todos lo que he leido hasta ahora, en general usa scaffold para
cada modelo y generar el CRUD. El tema esta en que si por ejemplo tengo
un apartado de noticias y otro de articulos (por decir algo), scaffold
me genera todo el tinglado para cada uno. Tengo una clase noticia y una
articulo con todos sus metodos para edit, show, etc etc. Todo esto esta
repetido. Al fin y al cabo no podria hacer una clase por encima de estas
de forma abstracta que me defina estos metodos en general? Luego desde
el método edit de articulo solo deberia llamar al metodo edit de la
madre y indicarle el objeto concreto no?
La idea seria también aprovechar las vistas de edit, show … la única
concreta de cada uno seria el _form para introducir los datos.

No se si me explico bien. Me parece algo muy natural, pero no se como
hacerlo porque voy pez tanto de ruby como de rails.

En fin, voy estudiandome el tinglado de mientras

Gracias

El Viernes, 17 de Noviembre de 2006 19:17, Ivan Ruiz Sevilla
-[dtres.es]-
escribió:> Tengo que desarrollar una aplicación en Ruby on Rails, y me gustaría

disponer de manuales tanto para Ruby como para Rails. Ya os digo de
antemano que no tengo ni idea, y me gustaría empezar poco a poco.

¿Has buscado en Google? hay unos 800 :wink:

PD: Al escribir un correo a la lista crea uno nuevo desde cero y no le
des
a “Responder” sobre otro correo pues el tuyo aparecería colgando de su
hilo
(como es el caso).

Saludos.

Inicialmente te recomiendo un clase introductorio de Rails,

Este artículo es muy bueno, nos enseña que es el controlador, el modelo
y la vista, y cómo se relacionan entre ellos.

Quiero hacer una aplicación típica web con gestión de contenidos de lo
más sencilla para jugar. Creo que si me sirve rails para esto.

Si

Total. Todos lo que he leido hasta ahora, en general usa scaffold para
cada modelo y generar el CRUD.

Scaffold es una ayuda para generar app rápidamente pero no debe
reeemplazar a la app final
En general te recomiendo que dentro del controlador agregues

class XxxxController < ApplicationController
scaffold :modelo

end

Esto te dará la misma funcionalidad que generar el scaffold con
script/generate
|
|ruby script\generate scaffold Xxxxx

|
Siembargo el CRUD y las vistas se generan dinámicamente.
La ventaja es que podrás ir personalizando incrementalmente la
funcionalidad
|

class XxxxController < ApplicationController
scaffold :modelo

reemplazamos el edit del scaffold por un edit personalizado para

nuestra app
def edit

end

end

La idea básica en Rails es, tenemos vistas donde mostramos la info,
desde la vista podemos acceder el modelo (tablas) para mostrar los datos
y, usuando el submit del formulario se invoca una acción (método) del
controlador (clase), desde la acción todos los campos del formulario
están accesibles através del hash params[]. Insertar o actualizar datos
es tan simple como pasar los datos de params hacía una instancia del
modelo de la tabla correspondiente - de uno a uno o en bloque con una
sola operación.
Siembargo esto no es todo. Rails encapsula años de experiencia en
desarrollo Web, ej: desde el modelo podemos en forma simple hacer las
validaciones de los datos, por medio de filtros (o callbacks) podemos
validar si el usuario está autenticado o si su sesión aún está activa,
además el sistema de vistas nos permite construir la página a partir de
fragmentos usando layouts y parciales; sistema de caching integrado, y
más facilidades que conforme vayas necesitando podrás ir explorando.
Te deseo mucho éxito, haz llegado a una gran herramienta de desarrollo
Web.

PD: La segunda parte del tutorial es esta

Jaume wrote:

Pero entonces, Scaffold para que sirve exactamente? para hacer una demo
a un colega en unos segundos y que haga :open_mouth: jejejeje

Exacto jeje. O también para nosotros los programadores que no
necesitamos un UI de usuario final. Aunque cuando se necesite,
progresivamente se va mejorando y hermoseando.

Me parece muy interesante todo el mundillo de rails, aun así considero
que tantas convenciones dificultan un poco el aprendizaje. Hay veces que
no tienes claro que esta pasado porque por todos lados hay código
suponiendo cosas. Es como mágico no? :stuck_out_tongue:

Si, son como ideas sueltas que hay que interconectar, Rails es un
standard, hay que conocerlo para poder aprovecharse de él. Aunque como
pistas te diré que se basa en principios, el primero la programación
dinámica y least surprise - debido al Ruby y DRY (Don´t Repeat Yourself)

  • principio agile - creo.
    Si, hay mucho que leer y que estudiar, pero todo está disponible en la
    red (al final algunos links, prueba también conseguirte el libro: Agile
    Web D. with Rails) sinembargo el RoR a diferencia de otros
    Frameworks dá satisfacción inmediata, en poco tiempo tienes una pequeña
    app funcionando. Prueba Struts o algún otro framework de Java, eso si es
    complicado y poco satisfactorio.

Links:

Api de RoR
http://api.rubyonrails.org/

Ruby Api, pues también se necesita conocer Ruby
http://www.ruby-doc.org/core/

Rails for Designers, una mirada a RoR de afuera hacia adentro
http://glu.ttono.us/articles/2006/03/21/rails-for-designers

Understanding Controllers, Controladores en RoR, qué, cómo, porqué,
cuándo

Understanding Views, Vistas en RoR, qué, cómo, porqué, cuándo

RoR cheat sheet, como hacer (casi) cualquier cosa en RoR, en la red
también hay una versión en español, imprime estas páginas y tenlas
siempre a la mano
http://blog.nanorails.com/pages/rails_1.1_cheat_sheet

Todos los mensajes que se han posteado a este foro, encontrarás muchas
cuestiones resueltas
http://lists.simplelogica.net/pipermail/ror-es/

Wiki de RoR, bastante información y problemas resueltos en las secciones
HowTo…
http://wiki.rubyonrails.org/rails

Muchas Gracias Esteban, el manual es de gran ayuda.

Lo de crear con el scaffold de forma dinamica parece interesante y desde
luego mucho más limpio por lo que hace a código, pero en cuanto a
rendimiento hay algo que decidir? No tengo ni idea , pero todas estas
“pequeñas” cosas que se van generado a lo grande no pueden causar
problemas de rendimineto?
Aunque sigo pensando que és más ordenado y claro tener una classe madre
con la funcionalidad común.

Pero entonces, Scaffold para que sirve exactamente? para hacer una demo
a un colega en unos segundos y que haga :open_mouth: jejejeje

Me parece muy interesante todo el mundillo de rails, aun así considero
que tantas convenciones dificultan un poco el aprendizaje. Hay veces que
no tienes claro que esta pasado porque por todos lados hay código
suponiendo cosas. Es como mágico no? :stuck_out_tongue:

Muchas gracias!

Jaume