Paseo por Django

Lightning Talks Dia Sábado 26 de Octubre en StartechConf 2013.

Transcript

1. jjdelc
2. Django y yo • <3 • ~5 años • $$ • </3 ?? …. <3!!
3. Django y yo • <3 • 6 años • $$ • </3 ?? …. <3!!
4. Fat models Class MyModel(Model): name = CharField(...) attr_1 = CharField(...) def …. def … def … def … def ... def …
5. Separar Storage de “Entidad” • Y eso.. • Crear otra clase independiente para representar una entidad separada del storage • Puedo tener varias representaciones distintas del mismo “registro” • Desacoplar el código de storage de el código de negocio
6. Hidratar de distintas fuentes • MyModelRepr.from_model(dj_model_in stance) • MyModelRepr.from_dict({...}) Test sin Django!
7. Fat Views • Igual que modelos, separar la lógica de un HTTP request • Se puede aprovechar Mixins, o delegación, lo que sea. • Permite testear la lógica sin necesidad de depender de un Request o un Response
8. Fat templates • Django templates son demasiado buenos • Caso utópico, prohibido dj models y querysets. • Usar un “Prerenderer” • Tests sin template engine! • Capacidad de profiling mucho más granular
9. Estructura de código • /myapp/ – models.py – forms.py – views.py • No escala, no es malo juntar forms y views en un archivo • Pensar en módulos y no en “apps”
10. Form Rendering != Validación • Cronjobs • File parsing • Los django Forms hacen muchas cosas y todos los ejemplos le dán un mismo uso
11. Opiniones? • Código Baclava (layeritis) • Sobreingenería? • Performance gains? • Demasiado código. • No es excluyente, es posible usar algunas ideas y migrar código conforme le proyecto crece