Re: Entorno de producción de aplicaciones web con python

[lasizoillo]

2008/10/22 Julio Napurí Carlos <julionc en gmail.com>:
>>> Interesante... por casualidad no conoces algún utilitario que haga el
>>> scaffolding (tipo rails) en pylons ?
>>
>>
>> Si me explicas como hace el scaffolding rails quiza te pueda comentar
>> algo que se parezca. Pero es que de rails ando muy perdido.
>
> Bueno. El Scaffolding [1] genera el CRUD en rails de manera
> automática. Le especificas el modelo (tabla) y genera el modelo, el
> contrololador y la vista (MVC). Esto para ahorrar tiempo en el diseño
> y enfocarme en la aplicación.

Creo que ese tipo de magia es para la que no está hecha SQLAlchemy.
SQLAlchemy esta basado en el patrón "Unit of Work"[1] y no el "Active
Record"[2], donde una clase representa a una tabla y un objeto un
registro de la misma.

La magia que tu pides es más de usar el patrón Active Record. El
patrón de SQLAlchemy ayuda a otro tipo de magia[3] que me gusta más
;-)
Con esa nueva magía es muy dificil tener una configuración estandard
generable automágicamente.

Si quieres usar tablas ya creadas para tu modelo sin tener que
escribir todos los campos que contienen puedes usar el parametro
autoload de las Tablas, pero de todas formas hay que escribir algo. Yo
personalmente prefiero escribir el model en python y que el me genere
él la base de datos (para el motor que sea). Aparte de que es más
fácil usar herramientas como miruku[4] para que me generen la
actualización del modelo mientras evoluciono la aplicación (tiene sus
carencias pero quita mucho curro).

Para mi el modelo no es una simpre representación de una base de
datos, sino donde se hace toda la logica de negocio. Soy más de pensar
en algo como lo que se comenta en el apartado "Fancy Classes"[5]. Y
eso no hay magia que la haga. Así no se hacen wikis en 10 minutos,
pero cuando tienes que hacer trabajos de un par de horas se acaba
ahorrando tiempo. Me gusta, por ejemplo, que el propio modelo sepa que
tiene que avisar al buscador para reindexar una página y que el
controlador se olvide de todas esas cosas (ver[6] para más info).

[1] http://www.sqlalchemy.org/docs/05/session.html#unitofwork_what
[2] http://martinfowler.com/eaaCatalog/activeRecord.html
[3] http://www.sqlalchemy.org/docs/05/session.html#unitofwork_partitioning
[4] http://trac.ollix.org/miruku/
[5] http://docs.pylonshq.com/models.html#working-with-databases-and-sqlalchemy
[6] http://www.sqlalchemy.org/docs/05/sqlalchemy_orm.html#docstrings_sqlalchemy.orm_MapperExtension

> Encontré un par de respuestas aquí [2], pero anda un poco verde la cosa.
> Lo que encontré:
> - AdminPylon
> - Restin
> - pails-admin
>
>

El "sufrir" haciendo el modelo no tiene por qué implicar seguir
haciendolo para generar la presentación/administración:
 * http://code.google.com/p/formalchemy/
 * http://code.google.com/p/dbsprockets/wiki/DBMechanic
 * ...

Aunque quizá no necesites tantas alforjas para ese viaje y te venga
mejor usar TurboGears y CrudTemplate:
 * http://docs.turbogears.org/1.0/CRUDTemplate

Como todo, la programación también va por gustos ;-)

Un saludo:

Javi
_______________________________________________
Lista de correo Python-es 
http://listas.aditel.org/listinfo/python-es
FAQ: http://listas.aditel.org/faqpyes