Django, La Guia Definitiva

Django, La guia DenitivaVersin

Django Software Foundation

July 04, 2012

ndice general

1. EL LIBRO DE DJANGO 1.1. Getting help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. CAPITULOS: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Captulo 1: Introduccin a Django 2.1. Qu es un Framework Web? 2.2. El patrn de diseo MVC . . 2.3. La historia de Django . . . . 2.4. Cmo leer este libro . . . . . 2.5. Qu sigue? . . . . . . . . . . 3. Captulo 2: Empezando 3.1. Instalar Python . . . . . . . 3.2. Instalar Django . . . . . . . 3.3. Congurar la base de datos 3.4. Comenzar un proyecto . . 3.5. Qu sigue? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 1 3 3 4 6 7 8 9 9 9 11 12 14 15 15 16 18 21 21 22 25 27 29 29 30 37 42 43 44 49 52

4. Captulo 3: Los principios de las pginas Web dinmicas 4.1. Tu primera Vista: Contenido dinmico . . . . . . . . 4.2. Mapeando URLs a Vistas . . . . . . . . . . . . . . . . 4.3. Cmo procesa una peticin Django . . . . . . . . . . 4.4. URLconfs y el acoplamiento dbil . . . . . . . . . . . 4.5. Errores 404 . . . . . . . . . . . . . . . . . . . . . . . . 4.6. Tu segunda Vista: URLs dinmicas . . . . . . . . . . . 4.7. Pginas de error bonitas con Django . . . . . . . . . . 4.8. Qu sigue? . . . . . . . . . . . . . . . . . . . . . . . . 5. Captulo 4: El sistema de plantillas de Django 5.1. Sistema bsico de plantillas . . . . . . . . 5.2. Empleo del sistema de plantillas . . . . . 5.3. Etiquetas bsicas de plantillas y ltros . . 5.4. Filosofa y Limitaciones . . . . . . . . . . 5.5. Uso de plantillas en las vistas . . . . . . . 5.6. Cargadores de plantillas . . . . . . . . . . 5.7. Herencia de plantillas . . . . . . . . . . . 5.8. Qu sigue? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6. Captulo 5: Interactuar con una base de datos: Modelos 6.1. La manera tonta de hacer una consulta a la base de datos en las vistas 6.2. El patrn de diseo MTV . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3. Conguracin de la base de datos . . . . . . . . . . . . . . . . . . . . . . 6.4. Tu primera aplicacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5. Denir modelos en Python . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6. Tu primer modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7. Instalar el modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.8. Acceso bsico a datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.9. Agregar strings de representacin del modelo . . . . . . . . . . . . . . . 6.10. Insertar y actualizar datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.11. Seleccionar objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.12. Eliminar objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.13. Realizar cambios en el esquema de una base de datos . . . . . . . . . . . 6.14. Qu sigue? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. Captulo 6: El sitio de Administracin Django 7.1. Activar la interfaz de administracin . . . . . . . . . . . . 7.2. Usar la interfaz de administracin . . . . . . . . . . . . . . 7.3. Personalizar la interfaz de administracin . . . . . . . . . 7.4. Personalizar la apariencia de la interfaz de administracin 7.5. Personalizar la pgina ndice del administrador . . . . . . 7.6. Cundo y porqu usar la interfaz de administracin . . . . 7.7. Qu sigue? . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. Captulo 7: Procesamiento de formularios 8.1. Bsquedas . . . . . . . . . . . . . . . . . . . . 8.2. El formulario perfecto . . . . . . . . . . . . 8.3. Creacin de un formulario para comentarios 8.4. Procesamiento de los datos suministrados . 8.5. Nuestras propias reglas de validacin . . . . 8.6. Una presentacin personalizada . . . . . . . 8.7. Creando formularios a partir de Modelos . . 8.8. Qu sigue? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53 53 54 55 57 58 59 61 63 64 65 66 70 70 73 75 75 76 84 86 86 86 87 89 89 91 92 94 96 96 97 98

9. Captulo 8: Vistas avanzadas y URLconfs 99 9.1. Trucos de URLconf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 9.2. Incluyendo otras URLconfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 9.3. Qu sigue? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 10. Captulo 9: Vistas genricas 10.1. Usar vistas genricas . . . . . 10.2. Vistas genricas de objetos . 10.3. Extender las vistas genricas 10.4. Qu sigue? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 113 114 116 120 121 121 122 126 127 136 137 138 138

11. Captulo 10: Extender el sistema de plantillas 11.1. Revisin del lenguaje de plantillas . . . . . . . . . . . . 11.2. Procesadores de contexto . . . . . . . . . . . . . . . . . 11.3. Detalles internos de la carga de plantillas . . . . . . . . 11.4. Extender el sistema de plantillas . . . . . . . . . . . . . 11.5. Escribir cargadores de plantillas personalizados . . . . 11.6. Usar la referencia de plantillas incorporadas . . . . . . 11.7. Congurar el sistema de plantillas en modo autnomo 11.8. Qu sigue? . . . . . . . . . . . . . . . . . . . . . . . . .

12. Captulo 11: Generacin de contenido no HTML 139 12.1. Lo bsico: Vistas y tipos MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 12.2. Produccin de CSV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

12.3. 12.4. 12.5. 12.6. 12.7.

Generar PDFs . . . . . . . . . . . . . . . Otras posibilidades . . . . . . . . . . . . El Framework de Feeds de Sindicacin El framework Sitemap . . . . . . . . . . Qu sigue? . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

141 143 144 149 153 155 155 158 162 163 172 174 177 177 181 181 183 184 187 187 187 189 189 190 195 198 199 201 203 203 205 205 206 206 208 211 213 213 215 217 217 219 220 221 223 226 226 227 228 230 231 233

13. Captulo 12: Sesiones, usuario e inscripciones 13.1. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.2. El entorno de sesiones de Django . . . . . . . . . . . . . . . 13.3. Usuarios e identicacin . . . . . . . . . . . . . . . . . . . 13.4. Utilizando usuarios . . . . . . . . . . . . . . . . . . . . . . 13.5. El resto de detalles: permisos, grupos, mensajes y perles 13.6. Qu sigue? . . . . . . . . . . . . . . . . . . . . . . . . . . . 14. Captulo 13: Cache 14.1. Activar el Cache . . . . . . . . . . . . 14.2. La cache por sitio . . . . . . . . . . . . 14.3. Cache por vista . . . . . . . . . . . . . 14.4. La API de cache de bajo nivel . . . . . 14.5. Caches upstream . . . . . . . . . . . . 14.6. Otras optimizaciones . . . . . . . . . . 14.7. Orden de MIDDLEWARE_CLASSES 14.8. Qu sigue? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15. Captulo 14: Otros sub-frameworks contribuidos 15.1. La biblioteca estndar de Django . . . . . . . 15.2. Sites . . . . . . . . . . . . . . . . . . . . . . . 15.3. Flatpages . . . . . . . . . . . . . . . . . . . . 15.4. Redirects . . . . . . . . . . . . . . . . . . . . . 15.5. Proteccin contra CSRF . . . . . . . . . . . . 15.6. Hacer los datos ms humanos . . . . . . . . 15.7. Filtros de marcado . . . . . . . . . . . . . . . 15.8. Qu sigue? . . . . . . . . . . . . . . . . . . . 16. Captulo 15: Middleware 16.1. Qu es middleware . . . . . 16.2. Instalacin de Middleware 16.3. Mtodos de un Middleware 16.4. Middleware incluido . . . . 16.5. Qu sigue? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17. Captulo 16: Integracin con Base de datos y Aplicaciones existentes 17.1. Integracin con una base de datos existente . . . . . . . . . . . . 17.2. Integracin con un sistema de autenticacin . . . . . . . . . . . 17.3. Integracin con aplicaciones web existentes . . . . . . . . . . . . 17.4. Qu sigue? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18. Captulo 17: Extender la Interfaz de Administracin de Django 18.1. El Zen de la aplicacin Admin . . . . . . . . . . . . . . . . . 18.2. Pesonalizar las plantillas de la interfaz . . . . . . . . . . . . 18.3. Crear vistas de administracin personalizadas . . . . . . . . 18.4. Sobreescribir vistas incorporadas . . . . . . . . . . . . . . . . 18.5. Qu sigue? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19. Captulo 18: Internacionalizacin 19.1. Especicando cadenas de traduccin en cdigo Python . . . 19.2. Especicando cadenas de traduccin en cdigo de plantillas 19.3. Creando archivos de idioma . . . . . . . . . . . . . . . . . . 19.4. Cmo descubre Django la preferencia de idioma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19.5. 19.6. 19.7. 19.8. 19.9.

La vista de redireccin set_language . . . . . . . . Usando traducciones en tus propios proyectos . . Traducciones y JavaScript . . . . . . . . . . . . . . Notas para usuarios familiarizados con gettext Qu sigue? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

235 236 236 238 238 239 239 240 241 242 243 244 245 246 247 247 249 250 251 251 255 260 264 266 267 269

20. Captulo 19: Seguridad 20.1. El tema de la seguridad en la Web 20.2. Inyeccin de SQL . . . . . . . . . . 20.3. Cross-Site Scripting (XSS) . . . . . 20.4. Cross-Site Request Forgery . . . . 20.5. Session Forging/Hijacking . . . . 20.6. Inyeccin de cabeceras de email . 20.7. Directory Traversal . . . . . . . . . 20.8. Exposicin de mensajes de error . 20.9. Palabras nales sobre la seguridad 20.10. Qu sigue? . . . . . . . . . . . . .

21. Captulo 20: Puesta en marcha de Django en un servidor 21.1. Nada Compartido . . . . . . . . . . . . . . . . . . . . 21.2. Un nota sobre preferencias personales . . . . . . . . . 21.3. Usando Django con Apache y mod_python . . . . . . 21.4. Usando Django con FastCGI . . . . . . . . . . . . . . 21.5. Escalamiento . . . . . . . . . . . . . . . . . . . . . . . 21.6. Ajuste de Performance . . . . . . . . . . . . . . . . . . 21.7. Qu sigue? . . . . . . . . . . . . . . . . . . . . . . . . 22. Apndice 23. Inicio: 24. Apndice A: Casos de estudio 24.1. Elenco . . . . . . . . . . . 24.2. Por qu Django? . . . . . 24.3. Comenzando . . . . . . . 24.4. Portando cdigo existente 24.5. Cmo les fue? . . . . . . 24.6. Estructura de Equipo . . 24.7. Implementacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

271 271 272 273 273 274 275 276 277 277 282 285 289 291 294 297 303 304 305 306 306 307 315 319 320 324

25. Apndice B: Referencia de la denicin de modelos 25.1. Campos . . . . . . . . . . . . . . . . . . . . . . . 25.2. Opciones Universales de Campo . . . . . . . . . 25.3. Relaciones . . . . . . . . . . . . . . . . . . . . . . 25.4. Opciones de los Metadatos del Modelo . . . . . 25.5. Managers . . . . . . . . . . . . . . . . . . . . . . 25.6. Mtodos de Modelo . . . . . . . . . . . . . . . . 25.7. Opciones del Administrador . . . . . . . . . . . 26. Apndice C: Referencia de la API de base de datos 26.1. Creando Objetos . . . . . . . . . . . . . . . . . 26.2. Grabando cambios de objetos . . . . . . . . . . 26.3. Recuperando objetos . . . . . . . . . . . . . . . 26.4. Caching y QuerySets . . . . . . . . . . . . . . . 26.5. Filtrando objetos . . . . . . . . . . . . . . . . . 26.6. Patrones de bsqueda . . . . . . . . . . . . . . 26.7. Bsquedas complejas con Objetos Q . . . . . . 26.8. Objetos Relacionados . . . . . . . . . . . . . . 26.9. Borrando Objectos . . . . . . . . . . . . . . . . . . . . . . . . .

26.10. Mtodos de Instancia Adicionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 26.11. Atajos (Shortcuts) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 26.12. Utilizando SQL Crudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 27. Apndice D: Referencia de las vistas genricas 27.1. Argumentos comunes a todas las vistas genricas 27.2. Vistas genricas simples . . . . . . . . . . . . . . . 27.3. Vistas de listado/detalle . . . . . . . . . . . . . . . 27.4. Vistas genricas basadas en fechas . . . . . . . . . 27.5. Vistas genericas para Crear/Modicar/Borrar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 327 328 329 333 341 345 345 347 348 349

28. Apndice E: Variables de conguracin 28.1. Qu es un archivo de conguracin . . . . . . . . . . . . . . . . . . . . . . . . 28.2. Indicando la conguracin: DJANGO_SETTINGS_MODULE . . . . . . . . . 28.3. Usando variables de conguracin sin jar DJANGO_SETTINGS_MODULE 28.4. Variables de conguracin disponibles . . . . . . . . . . . . . . . . . . . . . .

29. Apndice F: Etiquetas de plantilla y ltros predenidos 361 29.1. Etiquetas predenidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 29.2. Filtros predenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 30. Apndice G: El utilitario django-admin 379 30.1. Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 30.2. Acciones Disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 30.3. Opciones Disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 31. Apndice H: Objetos Peticin y Respuesta 389 31.1. HttpRequest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 31.2. HttpResponse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 32. Sobre el libro 33. Indices, glossary and tables 399 401

CAPTULO 1

EL LIBRO DE DJANGO

Todo lo que necesitas saber de Django (y algo mas)

1.1 Getting helpTienes Problemas? A nosotros nos gustaria ayudarte! Busca en la documentacin FAQ La respuesta a las preguntas mas comunes. El canal de IRC de Django donde los usuarios de Django se juntan a chatear y se ayudan unos a otros en tiempo real se juntan miles de usuarios para preguntar y responder dudas. Suscrbete gratuitamente en http://www.djangoproject.com/r/django-users (ingls) o http://groups.google.es/group/django-es (espaol). Reporta bugs a Django en su ticket tracker.

1.2 CAPITULOS:01.- INTRODUCCION A DJANGO 02.- EMPEZANDO 03.- LOS PRINCIPIOS DE LAS PAGINAS WEB DINAMICAS 04.- EL SISTEMA DE PLANTILLAS DE DJANGO 05.- INTERACTUAR CON UNA BASE DE DATOS 06.- EL SITIO DE ADMINISTRACION DE DJANGO 07.- PROCESAMIENTO DE FORMULARIOS 08.- VISTAS AV ANZADAS Y URLCONFS 09.- VISTAS GENERICAS 10.- EXTENDIENDO EL SISTEMA DE PLANTILLAS 11.- GENERACION DE CONTENIDO NO HTML 12.- SESIONES, USUARIOS E INSCRIPCIONES 13.- CACHE 14.- BATERIAS INCLUIDAS EN DJANGO 15.- MIDDLEWARE

Django, La guia Denitiva, Versin

16.- INTEGRACION CON BASE DE DATOS Y APLICACIONES EXISTENTES 17.- EXTENDIENDO LA INTERFAZ DE ADMINISTRACION DE DJANGO 18.- INTERNACIONALIZACION 19.- SEGURIDAD 20.- IMPLEMENTANDO DJANGO

Captulo 1. EL LIBRO DE DJANGO

CAPTULO 2

Captulo 1: Introduccin a Django

Este libro es sobre Django, un framework de desarrollo Web que ahorra tiempo y hace que el desarrollo Web sea divertido. Utilizando Django puedes crear y mantener aplicaciones Web de alta calidad con un mnimo esfuerzo. En el mejor de los casos, el desarrollo web es un acto entretenido y creativo; en el peor, puede ser una molestia repetitiva y frustrante. Django te permite enfocarte en la parte creativa la parte divertida de tus aplicaciones Web al mismo tiempo que mitiga el esfuerzo de las partes repetitivas. De esta forma, provee un alto nivel de abstraccin de patrones comunes en el desarrollo Web, atajos para tareas frecuentes de programacin y convenciones claras sobre cmo solucionar problemas. Al mismo tiempo, Django intenta no entrometerse, dejndote trabajar fuera del mbito del framework segn sea necesario. El objetivo de este libro es convertirte en un experto de Django. El enfoque es doble. Primero, explicamos en profundidad lo que hace Django, y cmo crear aplicaciones Web con l. Segundo, discutiremos conceptos de alto nivel cuando se considere apropiado, contestando la pregunta Cmo puedo aplicar estas herramientas de forma efectiva en mis propios proyectos? Al leer este libro, aprenders las habilidades necesarias para desarrollar sitios Web poderosos de forma rpida, con cdigo limpio y de fcil mantenimiento. En este captulo ofrecemos una visin general de Django.

2.1 Qu es un Framework Web?Django es un miembro importante de una nueva generacin de frameworks Web. Y qu signica ese trmino exactamente? Para contestar esa pregunta, consideremos el diseo de una aplicacin Web escrita usando el estndar Common Gateway Interface (CGI), una forma popular de escribir aplicaciones Web alrededor del ao 1998. En esa poca, cuando escribas una aplicacin CGI, hacas todo por ti mismo el equivalente a hacer una torta desde cero . Por ejemplo, aqu hay un script CGI sencillo, escrito en Python, que muestra los diez libros ms recientemente publicados de una base de datos:#!/usr/bin/python import MySQLdb print " Content-Type: text/html " print print " Libros " print " " print " Los ultimos 10 libros " print "

"

3


conexion = MySQLdb.connect(user= yo , passwd= dejame_entrar , db= mi_base ) cursor = conexion.cursor() cursor.execute( " SELECT nombre FROM libros ORDER BY fecha_pub DESC LIMIT 10 " ) for fila in cursor.fetchall(): print "

" % fila[0] print " " print " " conexion.close()

Este cdigo es fcil de entender. Primero imprime una lnea de Content-Type, seguido de una lnea en blanco, tal como requiere CGI. Imprime HTML introductorio, se conecta a la base de datos y ejecuta una consulta que obtiene los diez libros ms recientes. Hace un bucle sobre esos libros y genera una lista HTML desordenada. Finalmente imprime el cdigo para cerrar el HTML y cierra la conexin con la base de datos. Con una nica pgina dinmica como esta, el enfoque desde cero no es necesariamente malo. Por un lado, este cdigo es sencillo de comprender incluso un desarrollador novato puede leer estas 16 lneas de Python y entender todo lo que hace, de principio a n . No hay ms nada que aprender; no hay ms cdigo para leer. Tambin es sencillo de utilizar: tan slo guarda este cdigo en un archivo llamado ultimoslibros.cgi, sube ese archivo a un servidor Web y visita esa pgina con un navegador. Pero a medida que una aplicacin Web crece ms all de lo trivial, este enfoque se desmorona y te enfrentas a una serie de problemas: Qu sucede cuando mltiples pginas necesitan conectarse a la base de datos? Seguro que ese cdigo de conexin a la base de datos no debera estar duplicado en cada uno de los scripts CGI, as que la forma pragmtica de hacerlo sera refactorizarlo en una funcin compartida. Debera un desarrollador realmente tener que preocuparse por imprimir la lnea de ContentType y acordarse de cerrar la conexin con la base de datos? Este tipo de cdigo repetitivo reduce la productividad del programador e introduce la oportunidad para que se cometan errores. Estas tareas de conguracin y cierre estaran mejor manejadas por una infraestructura comn. Qu sucede cuando este cdigo es reutilizado en mltiples entornos, cada uno con una base de datos y contraseas diferentes? En ese punto, se vuelve esencial alguna conguracin especca del entorno. Qu sucede cuando un diseador Web que no tiene experiencia programando en Python desea redisear la pgina? Lo ideal sera que la lgica de la pgina la bsqueda de libros en la base de datos est separada del cdigo HTML de la pgina, de modo que el diseador pueda hacer modicaciones sin afectar la bsqueda. Precisamente estos son los problemas que un framework Web intenta resolver. Un framework Web provee una infraestructura de programacin para tus aplicaciones, para que puedas concentrarte en escribir cdigo limpio y de fcil mantenimiento sin tener que reinventar la rueda. En resumidas cuentas, eso es lo que hace Django.

2.2 El patrn de diseo MVCComencemos con un rpido ejemplo que demuestra la diferencia entre el enfoque anterior y el empleado al usar un framework Web. As es como se podra escribir el cdigo CGI anterior usando Django:# models.py (las tablas de la base de datos) from django.db import models class Book(models.Model): name = models.CharField(maxlength=50) pub_date = models.DateField()

Captulo 2. Captulo 1: Introduccin a Django

# views.py (la parte lgica) from django.shortcuts import render_to_response from models import Book def latest_books(request): book_list = Book.objects.order_by( -pub_date )[:10] return render_to_response( latest_books.html , { book_list : book_list}) # urls.py (la configuracin URL) from django.conf.urls.defaults import * import views urlpatterns = patterns( , ( r latest/$ , views.latest_books), ) # latest_books.html (la plantilla) Books Books

{% for book in book_list %}

{% endfor %}

Todava no es necesario preocuparse por los detalles de cmo funciona esto tan slo queremos que te acostumbres al diseo general . Lo que hay que notar principalmente en este caso son las cuestiones de separacin: El archivo models.py contiene una descripcin de la tabla de la base de datos, como una clase Python. A esto se lo llama el modelo. Usando esta clase se pueden crear, buscar, actualizar y borrar entradas de tu base de datos usando cdigo Python sencillo en lugar de escribir declaraciones SQL repetitivas. El archivo views.py contiene la lgica de la pgina, en la funcin latest_books(). A esta funcin se la denomina vista. El archivo urls.py especica qu vista es llamada segn el patrn URL. En este caso, la URL /latest/ ser manejada por la funcin latest_books(). El archivo latest_books.html es una plantilla HTML que describe el diseo de la pgina. Tomadas en su conjunto, estas piezas se aproximan al patrn de diseo Modelo-Vista-Controlador (MVC). Dicho de manera ms fcil, MVC dene una forma de desarrollar software en la que el cdigo para denir y acceder a los datos (el modelo) est separado del pedido lgico de asignacin de ruta (el controlador), que a su vez est separado de la interfaz del usuario (la vista). Una ventaja clave de este enfoque es que los componentes tienen un acoplamiento dbil (N. de T.: por loosely coupled) entre s. Eso signica que cada pieza de la aplicacin Web que funciona sobre Django tiene un nico propsito clave, que puede ser modicado independientemente sin afectar las otras piezas. Por ejemplo, un desarrollador puede cambiar la URL de cierta parte de la aplicacin sin afectar la implementacin subyacente. Un diseador puede cambiar el HTML de una pgina sin tener que tocar el cdigo Python que la renderiza. Un administrador de base de datos puede renombrar una tabla de la base de datos y especicar el cambio en un nico lugar, en lugar de tener que buscar y reemplazar en varios archivos. En este libro, cada componente tiene su propio captulo. Por ejemplo, el Captulo 3 trata sobre las vistas, el Captulo 4 sobre las plantillas, y el Captulo 5 sobre los modelos. El Captulo 5 profundiza tambin en 2.2. El patrn de diseo MVC 5

la losofa MVC de Django.

2.3 La historia de DjangoAntes de continuar con ms cdigo, deberamos tomarnos un momento para explicar la historia de Django. Es til entender por qu se cre el framework, ya que el conocimiento de la historia pone en contexto la razn por la cual Django trabaja de la forma en que lo hace. Si has estado creando aplicaciones Web por un tiempo, probablemente ests familiarizado con los problemas del ejemplo CGI presentado con anterioridad. El camino clsico de un desarrollador Web es algo como esto: 1. Escribir una aplicacin Web desde cero. 2. Escribir otra aplicacin Web desde cero. 3. Darse cuenta de que la aplicacin del paso 1 tiene muchas cosas en comn con la aplicacin del paso 2. 4. Refactorizar el cdigo para que la aplicacin 1 comparta cdigo con la aplicacin 2. 5. Repetir los pasos 2-4 varias veces. 6. Darse cuenta de que acabamos de inventar un framework. As es precisamente como fue creado Django. Django naci naturalmente de aplicaciones de la vida real escritas por un equipo de desarrolladores Web en Lawrence, Kansas. Naci en el otoo boreal de 2003, cuando los programadores Web del diario Lawrence Journal-World, Adrian Holovaty y Simon Willison, comenzaron a usar Python para crear sus aplicaciones. El equipo de The World Online, responsable de la produccin y mantenimiento de varios sitios locales de noticias, prosperaban en un entorno de desarrollo dictado por las fechas lmite del periodismo. Para los sitios incluidos LJWorld.com, Lawrence.com y KUsports.com los periodistas (y los directivos) exigan que se agregaran nuevas caractersticas y que aplicaciones enteras se crearan a una velocidad vertiginosa, a menudo con slo das u horas de preaviso. Es as que Adrian y Simon desarrollaron por necesidad un framework de desarrollo Web que les ahorrara tiempo era la nica forma en que podan crear aplicaciones mantenibles en tan poco tiempo . En el verano boreal de 2005, luego de haber desarrollado este framework hasta el punto en que estaba haciendo funcionar la mayora de los sitios World Online, el equipo de World Online, que ahora inclua a Jacob Kaplan-Moss, decidi liberar el framework como software de cdigo abierto. Lo liberaron en julio de 2005 y lo llamaron Django, por el guitarrista de jazz Django Reinhardt. A pesar de que Django ahora es un proyecto de cdigo abierto con colaboradores por todo el mundo, los desarrolladores originales de World Online todava aportan una gua centralizada para el crecimiento del framework, y World Online colabora con otros aspectos importantes tales como tiempo de trabajo, materiales de marketing, y hosting/ancho de banda para el Web site del framework (http://www.djangoproject.com/). Esta historia es relevante porque ayuda a explicar dos cuestiones clave. La primera es el punto dulce de Django. Debido a que Django naci en un entorno de noticias, ofrece varias caractersticas (en particular la interfaz admin, tratada en el Captulo 6 que son particularmente apropiadas para sitios de contenido sitios como eBay, craigslist.org y washingtonpost.com que ofrecen informacin basada en bases de datos . (De todas formas, no dejes que eso te quite las ganas a pesar de que Django es particularmente bueno para desarrollar esa clase de sitios, eso no signica que no sea una herramienta efectiva para crear cualquier tipo de sitio Web dinmico . Existe una diferencia entre ser particularmente efectivo para algo y no ser efectivo para otras cosas). La segunda cuestin a resaltar es cmo los orgenes de Django le han dado forma a la cultura de su comunidad de cdigo abierto. Debido a que Django fue extrado de cdigo de la vida real, en lugar de ser un ejercicio acadmico o un producto comercial, est especialmente enfocado en resolver problemas de desarrollo Web con los que los desarrolladores de Django se han encontrado y con los que continan encontrndose . Como resultado de eso, Django es activamente mejorado casi diariamente. Los 6 Captulo 2. Captulo 1: Introduccin a Django

desarrolladores del framework tienen un alto grado de inters en asegurarse de que Django les ahorre tiempo a los desarrolladores, produzca aplicaciones que son fciles de mantener y rindan bajo mucha carga. Aunque existan otras razones, los desarrolladores estn motivados por sus propios deseos egostas de ahorrarse tiempo a ellos mismos y disfrutar de sus trabajos. (Para decirlo sin vueltas, se comen su propia comida para perros).

2.4 Cmo leer este libroAl escribir este libro, tratamos de alcanzar un balance entre legibilidad y referencia, con una tendencia a la legibilidad. Nuestro objetivo con este libro, como se mencion anteriormente, es hacerte un experto en Django, y creemos que la mejor manera de ensear es a travs de la prosa y numerosos ejemplos, en vez de proveer un exhaustivo pero intil catlogo de las caractersticas de Django (Como alguien dijo una vez, no puedes esperar ensearle a alguien cmo hablar simplemente ensendole el alfabeto). Con eso en mente, te recomendamos que leas los captulos del 1 al 7 en orden. Ellos forman los fundamentos de cmo se usa Django; una vez que los hayas ledo, sers capaz de construir sitios Web que funcionan sobre Django. Los captulos restantes, los cuales se enfocan en caractersticas especcas de Django, pueden ser ledos en cualquier orden. Los apndices son para referencia. Ellos, junto con la documentacin libre en http://www.djangoproject.com/, son probablemente lo que releers de vez en cuando para recordar la sintaxis o buscar un resumen rpido de lo que hacen ciertas partes de Django.

2.4.1 Conocimientos de programacin requeridosLos lectores de este libro deben comprender las bases de la programacin orientada a objetos e imperativa: estructuras de control (if, while y for), estructuras de datos (listas, hashes/diccionarios), variables, clases y objetos. La experiencia en desarrollo Web es, como podrs esperar, muy til, pero no es requisito para leer este libro. A lo largo del mismo, tratamos de promover las mejores prcticas en desarrollo Web para los lectores a los que les falta este tipo de experiencia.

2.4.2 Conocimientos de Python requeridosEn esencia, Django es sencillamente una coleccin de bibliotecas escritas en el lenguaje de programacin Python. Para desarrollar un sitio usando Django escribes cdigo Python que utiliza esas bibliotecas. Aprender Django, entonces, es slo cuestin de aprender a programar en Python y comprender cmo funcionan las bibliotecas Django. Si tienes experiencia programando en Python, no deberas tener problema en meterte de lleno. En conjunto, el cdigo Django no produce magia negra (es decir, trucos de programacin cuya implementacin es difcil de explicar o entender). Para ti, aprender Django ser slo cuestin de aprender las convenciones y APIs de Django. Si no tienes experiencia programando en Python, te espera una grata sorpresa. Es fcil de aprender y muy divertido de usar. A pesar de que este libro no incluye un tutorial completo de Python, s hace hincapi en las caractersticas y funcionalidades de Python cuando se considera apropiado, particularmente cuando el cdigo no cobra sentido de inmediato. An as, recomendamos leer el tutorial ocial de Python, disponible en http://pyspanishdoc.sourceforge.net/tut/tut.html o su versin ms reciente en ingls en http://docs.python.org/tut/. Tambin recomendamos el libro libre y gratuito de Mark Pilgrim Inmersin en Python, disponible en http://es.diveintopython.org/ y publicado en ingls en papel por Apress.

2.4. Cmo leer este libro

2.4.3 Nuevas caractersticas de DjangoTal como hicimos notar anteriormente, Django es mejorado con frecuencia, y probablemente tendr un gran nmero de nuevas e incluso esenciales caractersticas para cuando este libro sea publicado. Por ese motivo, nuestro objetivo como autores de este libro es doble: Asegurarnos que este libro sea a prueba de tiempo tanto como nos sea posible, para que cualquier cosa que leas aqu todava sea relevante en futuras versiones de Django. Actualizar este libro continuamente en el sitio Web en ingls, http://www.djangobook.com/, para que puedas acceder a la mejor y ms reciente documentacin tan pronto como la escribimos. Si quieres implementar con Django algo que no est explicado en este libro, revisa la versin ms reciente de este libro en el sitio Web antes mencionado y tambin revisa la documentacin ocial de Django. Obteniendo ayuda: Para ayuda con cualquier aspecto de Django desde instalacin y diseo de aplicaciones, hasta diseo de bases de datos e implementaciones sintete libre de hacer preguntas online. En la lista de correo en ingls de usuarios de Django se juntan miles de usuarios para preguntar y responder dudas. Suscrbete gratuitamente en http://www.djangoproject.com/r/django-users (ingls) o http://groups.google.es/group/django-es (espaol). El canal de IRC de Django donde los usuarios de Django se juntan a chatear y se ayudan unos a otros en tiempo real. nete a la diversin en #django (ingls) o #django-es (espaol) en la red de IRC Freenode.

2.5 Qu sigue?En el Captulo 2, a continuacin, empezaremos con Django, explicando su instalacin y conguracin inicial.

Captulo 2. Captulo 1: Introduccin a Django

CAPTULO 3

Captulo 2: Empezando

Creemos que es mejor empezar con fuerza. En los captulos que le siguen a este descubrirs los detalles y el alcance del framework Django, pero por ahora, confa en nosotros, este captulo es divertido. Instalar Django es fcil. Django se puede usar en cualquier sistema que corra Python, por eso es posible instalarlo de varias maneras. En este captulo explicamos las situaciones ms comunes de instalacin de Django. El Captulo 20 explica cmo utilizar Django en produccin.

3.1 Instalar PythonDjango est escrito 100 % en puro cdigo Python, as que necesitars instalar Python en tu computadora. Django necesita Python 2.3 o superior. Si ests usando Linux o Mac OS X probablemente ya tienes Python instalado. Escribe python en una terminal. Si ves algo as, Python est instalado:Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>>

Si ves un error como: ommand not found" u .orden no encontrada", tienes que bajar e instalar Python. Fjate en http://www.python.org/download/ para empezar. La instalacin es rpida y fcil.

3.2 Instalar DjangoEn esta seccin explicamos dos opciones de instalacin: instalar un lanzamiento ocial e instalar desde Subversion.

3.2.1 Instalar un lanzamiento ocialLa mayora de la gente querr instalar el lanzamiento ocial ms reciente de http://www.djangoproject.com/download/. Django usa el mtodo distutils estndar de instalacin de Python, que en el mundo de Linux es as: 1. Baja el tarball, que se llamar algo as como Django-version.tar.gz 2. tar xzvf Django-*.tar.gz 3. cd Django-*

4. sudo python setup.py install En Windows, recomendamos usar 7-Zip para manejar archivos comprimidos de todo tipo, incluyendo .tar.gz. Puedes bajar 7-Zip de http://www.djangoproject.com/r/7zip/. Cambia a algn otro directorio e inicia python. Si todo est funcionando bien, deberas poder importar el mdulo django:>>> import django >>> django.VERSION (TU VERSION)

Nota: El intrprete interactivo de Python es un programa de lnea de comandos que te permite escribir un programa Python de forma interactiva. Para iniciarlo slo ejecuta el comando python en la lnea de comandos. Durante todo este libro, mostraremos ejemplos de cdigo Python como si estuviesen escritos en el intrprete interactivo. El triple signo de mayor que (>>>) es el prompt de Python.

3.2.2 Instalar Django desde SubversionSi quieres trabajar sobre la versin de desarrollo, o si quieres contribuir con el cdigo de Django en s mismo, deberas instalar Django desde el repositorio de Subversion. Subversion es libre, es un sistema de control de versiones de cdigo abierto similar a CVS, y es el que el equipo de Django utiliza para administrar cambios en el cdigo base de Django. Puedes utilizar un cliente de Subversion para hacerte con el cdigo fuente ms actual de Django y, en cualquier momento, puedes actualizar tu copia local del cdigo de Django, conocido como un checkout local, para obtener los ltimos cambios y mejoras hechas por los desarrolladores de Django. Al ltimo cdigo de desarrollo de Django se hace referencia como el trunk. El equipo de Django ejecuta sitios de produccin sobre el trunk y procura permanecer estable. Para obtener el trunk de Django, sigue los siguientes pasos: 1. Asegrate de tener un cliente de Subversion instalado. Puedes conseguir este programa libremente desde http://subversion.tigris.org/, y puedes encontrar documentacin excelente en http://svnbook.red-bean.com/. 2. Haz un check out del trunk usando el comando http://code.djangoproject.com/svn/django/trunk djtrunk. svn co

3. Crea site-packages/django.pth y agrega el directorio djtrunk a este, o actualiza tu PYTHONPATH agregando djtrunk. 4. Incluye djtrunk/django/bin en el PATH de tu sistema. Este directorio incluye utilidades de administracin como django-admin.py. Consejo: Si los archivo .pth son nuevos para ti, puedes http://www.djangoproject.com/r/python/site-module/. aprender ms de ellos en

Luego de descargarlo desde Subversion y haber seguido los pasos anteriores, no necesitas ejecutar python setup.py install Acabas de hacer este trabajo a mano! Debido a que el trunk de Django cambia a menudo corrigiendo bugs y agregando funcionalidades, probablemente quieras actualizarlo con frecuencia a cada hora, si eres un obsesivo. Para actualizar el cdigo, solo ejecuta el comando svn update desde el directorio djtrunk. Cuando ejecutes este comando, Subversion contactar http://code.djangoproject.com, determinar si el cdigo ha cambiado, y actualizar tu versin local del cdigo con cualquier cambio que se haya hecho desde la ltima actualizacin. Es muy bueno.

Captulo 3. Captulo 2: Empezando

3.3 Congurar la base de datosEl nico prerequisito de Django es una instalacin funcionando de Python. Sin embargo, este libro se centra en una de las mejores funcionalidades de Django, el desarrollo de sitios web con soporte de base de datos, para esto necesitars instalar un servidor de base de datos de algn tipo, para almacenar tus datos. Si slo quieres comenzar a jugar con Django, salta a la seccin Captulo 20 pero crenos, querrs instalar una base de datos nalmente.Todos los ejemplos de este libro asumen que tienes una base de datos congurada. Hasta el momento de escribir esto, Django admite estos motores de base de datos: PostgreSQL (http://www.postgresql.org/) SQLite 3 (http://www.sqlite.org/) MySQL (http://www.mysql.com/) Oracle (http://www.oracle.com/) Se est trabajando para admitir Microsoft SQL Server. El sitio web de Django siempre contendr la ltima informacin acerca de las base de datos admitidas. A nosotros el que ms nos gusta es PostgreSQL, por razones que exceden el alcance de este libro, por eso lo mencionamos primero. Sin embargo, todos los motores que listamos aqu trabajan bien con Django. SQLite merece especial atencin como herramienta de desarrollo. Es un motor de base de datos extremadamente simple y no requiere ningn tipo de instalacin y conguracin del servidor. Es por lejos el ms fcil de congurar si slo quieres jugar con Django, y viene incluido en la biblioteca estndar de Python 2.5. En Windows, obtener los drivers binarios de la base de datos es a veces un proceso complicado. Ya que slo ests inicindote con Django, recomendamos usar Python 2.5 y el soporte incluido para SQLite. La compilacin de drivers puede ser estresante.

3.3.1 Usar Django con PostgreSQLSi ests utilizando PostgreSQL, necesitars el paquete psycopg disponible en http://www.djangoproject.com/r/python-pgsql/. Toma nota de la versin que ests usando (1 2); necesitars esta informacin luego. Si ests usando PostgresSQL en Windows, puedes encontrar los binarios precompilados de psycopg en http://www.djangoproject.com/r/python-pgsql/windows/.

3.3.2 Usar Django con SQLite 3Si ests usando una versin de Python igual o posterior a 2.5, ya tienes SQLite. Si ests trabajando con Python 2.4 o menor, necesitas SQLite 3 no la versin 2 desde http://www.djangoproject.com/r/sqlite/ y el paquete pysqlite desde http://www.djangoproject.com/r/python-sqlite/. Asegrate de tener pysqlite en una versin 2.0.3 o superior. En Windows, puedes omitir la instalacin separada de los binarios de SQLite, ya que estn enlazados dentro de los binarios de pysqlite.

3.3.3 Usar Django con MySQLDjango requiere MySQL 4.0 o superior; la versin 3.x no admite subconsultas anidadas ni algunas otras sentencias SQL perfectamente estndar. Tambin necesitas instalar el paquete MySQLdb desde http://www.djangoproject.com/r/python-mysql/. 3.3. Congurar la base de datos 11

3.3.4 Usar Django con OracleDjango trabaja con versiones servidor de Oracle 9i o mas alto, si estas usando oracle necesitas instalar cx_Oracle, usa versiones superiores ala 4.31 pero evita la version 5 ya que tiene un bug el controlador de esa versin.

3.3.5 Usar Django sin una base de datosComo mencionamos anteriormente, Django actualmente no requiere una base de datos. Si slo quieres usar este como un servidor dinmico de pginas que no use una base de datos, est perfectamente bien. Con esto dicho, ten en cuenta que algunas de las herramientas extras de Django requieren una base de datos, por lo tanto si eliges no usar una base de datos, perders estas utilidades. (Sealaremos estas utilidades a lo largo del libro).

3.4 Comenzar un proyectoUn proyecto es una coleccin de conguraciones para una instancia de Django, incluyendo conguracin de base de datos, opciones especcas de Django y conguraciones especcas de aplicaciones. Si esta es la primera vez que usas Django, tendrs que tener cuidado de algunas conguraciones iniciales. Crea un nuevo directorio para empezar a trabajar, por ejemplo algo como /home/username/djcode/, e ingresa a este directorio. Donde esta django-admin.py django-admin.py debera estar en el PATH de tu sistema si instalaste Django con la utilidad setup.py. Si hiciste un check out desde Subversion, puedes encontrarlo en djtrunk/django/bin. Como vas a utilizar con frecuencia django-admin.py, considera agregarlo a tu PATH. En Unix, puedes hacer un link simblico de /usr/local/bin, usando un comando como sudo ln -s /path/to/django/bin/django-admin.py /usr/local/bin/django-admin.py. En Windows, necesitars actualizar tu variable de entorno PATH . Ejecuta el comando django-admin.py startproject mysite para crear el directorio mysite en el directorio actual. Echemos un vistazo a lo que startproject cre:mysite/ manage.py mysite/ __init__.py settings.py urls.py wsgi.py

No es lo mismo que ves ? Si estamos viendo un arbol de directorios diferentes al anterior problablemente estamos usando una version de Django anterior. Estos archivos son los siguientes: mysite/: El Directorio que contiene nuestro projecto. Podemos cambiarle el nombre en cualquier momento sin afectar nuestro proyecto. manage.py: Una utilidad de lnea de comandos que te deja interactuar con este proyecto de Django de varias formas.

mysite/mysite/:El directorio de nuestro paquete que contiene nuestro projecto el cual es un paquete python y el que se usara para importar cualquier cosa dentro de el. mysite/__init__.py: Un archivo requerido para que Python trate a este directorio como un paquete (i.e. un grupo de mdulos). mysite/settings.py: Opciones/conguraciones para este proyecto de Django. mysite/urls.py: La declaracin de las URL para este proyecto de Django; una tabla de contenidos de tu sitio hecho con Django. mysite/wsgi.py: El archivo encargado de ser compatible con el servidor web.

3.4.1 Dnde debera estar este directorio?Si vienes de PHP, probablemente pondras el cdigo debajo de la carpeta raz del servidor web (en lugares como /var/www). Con Django, no tienes que hacer esto. No es una buena idea poner cualquier cdigo Python en la carpeta raz del servidor web, porque al hacerlo se arriesga a que la gente sea capaz de ver el cdigo en la web. Esto no es bueno para la seguridad. Pon tu cdigo en algn directorio fuera de la carpeta raz.

3.4.2 El servidor de desarrolloDjango incluye un servidor web ligero que puedes usar mientras ests desarrollando tu sitio. Incluimos este servidor para que puedas desarrollar tu sitio rpidamente, sin tener que lidiar con conguraciones de servidores web de produccin (i.e., Apache) hasta que ests listo para la produccin. Este servidor de desarrollo vigila tu cdigo a la espera de cambios y se reinicia automticamente, ayudndote a hacer algunos cambios rpidos en tu proyecto sin necesidad de reiniciar nada. Entra en el directorio mysite, si an no lo has hecho, y ejecuta el comando python manage.py runserver. Vers algo parecido a esto:Validating models... 0 errors found. Django version 1.0, using settings mysite.settings Development server is running at http://127.0.0.1:8000/ Quit the server with CONTROL-C.

Aunque el servidor de desarrollo es extremadamente til para, bueno, desarrollar, resiste la tentacin de usar este servidor en cualquier entorno parecido a produccin. El servidor de desarrollo puede manejar ablemente una sola peticin a la vez, y no ha pasado por una auditora de seguridad de ningn tipo. Cuando sea el momento de lanzar tu sitio, mira el Captulo 20 para informacin sobre cmo hacerlo con Django. Cambiar el host o el puerto Por defecto, el comando runserver inicia el servidor de desarrollo en el puerto 8000, escuchando slo conexiones locales. Si quieres cambiar el puerto del servidor, pasa este como un argumento de lnea de comandos:python manage.py runserver 8080

Tambin puedes cambiar las direcciones de IP que escucha el servidor. Esto es utilizado especialmente si quieres compartir el desarrollo de un sitio con otros desarrolladores. Lo siguiente:python manage.py runserver 0.0.0.0:8080

har que Django escuche sobre cualquier interfaz de red, permitiendo que los dems equipos puedan conectarse al servidor de desarrollo.

3.4. Comenzar un proyecto

Ahora que el servidor est corriendo, visita http://127.0.0.1:8000/ con tu navegador web. Vers una pgina de Bienvenido a Django sombreada con un azul pastel agradable. Funciona!

3.5 Qu sigue?Ahora que tienes todo instalado y el servidor de desarrollo corriendo, en el prximo captulo escribirs algo de cdigo bsico que muestra cmo servir pginas Web usando Django.

CAPTULO 4

Captulo 3: Los principios de las pginas Web dinmicas

En el captulo anterior, explicamos cmo crear un proyecto en Django y cmo poner en marcha el servidor de desarrollo de Django. Por supuesto, el sitio no hace nada til todava slo muestra el mensaje It worked!. Cambiemos eso. Este captulo presenta cmo crear paginas web dinmicas con Django.

4.1 Tu primera Vista: Contenido dinmicoLo primero que haremos es crear una pgina web que muestre la fecha y la hora actual. Este es un buen ejemplo de una pgina dinmica, porque el contenido de la misma no es esttico al contrario, los contenidos cambian de acuerdo con el resultado de un clculo (en este caso, el clculo de la hora actual). Este simple ejemplo no involucra una base de datos cualquier tipo de entrada del usuario, slo muestra la salida del reloj interno del servidor. Para crear esta pgina, crearemos una funcin de vista. Una funcin de vista, o vista en pocas palabras, es una simple funcin de Python que toma como argumento una peticin Web y retorna una respuesta Web. Esta respuesta puede ser el contenido HTML de la pgina web, una redireccin, o un error 404, o un documento XML, o una imagen... o en realidad, cualquier cosa. La vista en s contiene toda la lgica necesaria para retornar esa respuesta. El cdigo puede encontrarse donde quieras, mientras que se encuentre dentro de tu Python path. No hay otro requerimiento no hay magia, por as decirlo. Por poner el cdigo en algn lugar, creemos un archivo llamado views.py en el directorio mysite, el cual creamos en el captulo anterior. Esta es la vista que retorna la fecha y hora actual, como un documento HTML:from django.http import HttpResponse import datetime def current_datetime(request): now = datetime.datetime.now() html = " It is now return HttpResponse(html)

%s . " % now

Repasemos el cdigo anterior lnea a lnea: Primero, importamos la clase HttpResponse, la cual pertenece al mdulo django.http. Para ver ms detalles de los objetos HttpRequest y HttpResponse puedes consultar el Apndice H. Luego importamos el mdulo datetime de la biblioteca estndar de Python, el conjunto de mdulos tiles que vienen con Python. El mdulo datetime contiene varias funciones y clases para trabajar con fechas y horas, incluyendo una funcin que retorna la hora actual.

A continuacin, denimos la funcin llamada current_datetime. Esta es una funcin de vista. Cada funcin de vista toma como primer argumento un objeto HttpRequest, al que tpicamente se le asigna el nombre request. Nota que el nombre de la funcin de vista no importa; no tiene que ser nombrada de una determinada manera para que Django la reconozca. La llamamos current_datetime aqu, porque el nombre indica claramente lo que hace, pero se podra llamar super_duper_awesome_current_time, o algo ms repugnante. A Django no le interesa. La siguiente seccin explica cmo Django encuentra esta funcion. La primera lnea de cdigo dentro de la funcin calcula la fecha/hora actual, como un objeto datetime.datetime, y almacena el resultado en la variable local now. La segunda lnea de cdigo dentro de la funcin construye la respuesta HTML usando el formato de cadena de caracteres de Python. El %s dentro de la cadena de caracteres es un marcador de posicin, y el signo porcentaje despus de la cadena de caracteres, signica Reemplaza el %s por el valor de la variable now.. (S, el HTML es invlido, pero estamos tratando de mantener el ejemplo simple y corto) Por ltimo, la vista retorna un objeto HttpResponse que contiene la respuesta generada. Cada funcin de vista es responsable de retornar un objeto HttpResponse. (Hay excepciones, pero lo haremos ms adelante) Zona Horaria de Django Django incluye una opcin TIME_ZONE que por omisin es America/Chicago. Probablemente no es donde vivas, por lo que puedes cambiarlo en tu settings.py. Vese el Apndice E para ms detalles.

4.2 Mapeando URLs a VistasRepasemos, esta funcin de vista retorna un pgina HTML que contiene la fecha y hora actual. Pero cmo le decimos a Django que utilice ese cdigo?. Ah es donde vienen las URLconfs. Una URLconf es como una tabla de contenido para tu sitio web hecho con Django. Bsicamente, es un mapeo entre los patrones URL y las funciones de vista que deben ser llamadas por esos patrones URL. Es como decirle a Django, Para esta URL, llama a este cdigo, y para esta URL, llama a este otro cdigo. Recuerda que estas funciones de vista deben estar en tu Python path. Python Path Python path es la lista de directorios en tu sistema en donde Python buscar cuando uses la sentencia import de Python. Por ejemplo, supongamos que tu Python path tiene el valor [, /usr/lib/python2.4/site-packages, /home/username/djcode/]. Si ejecutas el cdigo Python from foo import bar, Python en primer lugar va a buscar el mdulo llamado foo.py en el directorio actual. (La primera entrada en el Python path, una cadena de caracteres vaca, signica el directorio actual.) Si ese archivo no existe, Python va a buscar el mdulo en /usr/lib/python2.4/site-packages/foo.py. Si ese archivo no existe, entonces probar en /home/username/djcode/foo.py. Finalmente, si ese archivo no existe, Python lanzar ImportError Si ests interesado en ver el valor de tu Python path, abre un interprete interactivo de Python y escribe import sys, seguido de print sys.path. Generalmente no tienes que preocuparte de asigarle valores al Python path Python y Django se encargan automticamente de hacer esas cosas por ti entre bastidores. (Si eres curioso, establecer el Python path es una de las cosas que hace el archivo manage.py).

Captulo 4. Captulo 3: Los principios de las pginas Web dinmicas

Cuando ejecutaste django-admin.py startproject en el captulo anterior, el script cre automticamente una URLconf por t: el archivo urls.py. Editemos ese archivo. Por omisin, se ver como:from django.conf.urls.defaults import * urlpatterns = patterns( , # Example: # (r^mysite/, include(mysite.apps.foo.urls.foo)), # Uncomment this for admin: (r^admin/, include(django.contrib.admin.urls)),

Repasemos el cdigo anterior lnea a lnea: La primera lnea importa todos los objetos desde el mdulo django.conf.urls.defaults, incluyendo una funcin llamada patterns. La segunda lnea llama a la funcin patterns() y guarda el resultado en una variable llamada urlpatterns. La funcin patterns() slo recibe un argumento la cadena de caracteres vaca. El resto de las lneas estn comentadas. (La cadena de caracteres puede ser usada para proveer un prejo comn para las funciones de vista, pero dejemos este uso ms avanzado para ms adelante). Lo principal que debemos notar aqu es la variable urlpatterns, la cual Django espera encontrar en tu mdulo ROOT_URLCONF. Esta variable dene el mapeo entre las URLs y el cdigo que manejan esas URLs. Por defecto, todo lo que est en URLconf est comentado tu aplicacin de Django es una pizarra blanca. (Como nota adicional, esta es la forma en la que Django saba que deba mostrar la pgina It worked! en el captulo anterior. Si la URLconf esta vaca, Django asume que acabas de crear el proyecto, por lo tanto, muestra ese mensaje). Editemos este archivo para exponer nuestra vista current_datetime:from django.conf.urls.defaults import * from mysite.views import current_datetime urlpatterns = patterns( , ( r ^time/$ , current_datetime), )

Hicimos dos cambios aqu. Primero, importamos la vista current_datetime desde el mdulo (mysite/views.py, que en la sintaxis de import de Python se traduce a mysite.views). Luego, agregamos la lnea (r^time/$, current_datetime),. Esta lnea hace referencia a un URLpattern es una tupla de Python en dnde el primer elemento es una expresin regular simple y el segundo elemento es la funcin de vista que usa para ese patrn. En pocas palabras, le estamos diciendo a Django que cualquier peticin a la URL /time ser manejada por la funcin de vista current_datetime. Algunas cosas que vale la pena resaltar: Notemos que, en este ejemplo, pasamos la funcin de vista current_datetime como un objeto sin llamar a la funcin. Esto es una caracterstica de Python (y otros lenguajes dinmicos): las funciones son objetos de primera clase, lo cual signica que puedes pasarlas como cualquier otra variable. Qu bueno!, no? La r en r^time/$ signica que ^time/$ es una cadena de caracteres en crudo de Python. Esto permite que las expresiones regulares sean escritas sin demasiadas sentencias de escape. Puedes excluir la barra al comienzo de la expresin ^time/$ para que coincida con /time/. Django automticamente agrega una barra antes de toda expresin. A primera vista esto parece raro, pero una URLconf puede ser incluida en otra URLconf, y el dejar la barra de lado simplica mucho las cosas. Esto se retoma en el Captulo 8.

4.2. Mapeando URLs a Vistas

El caracter acento circunejo (^) y el carcter signo de dlar ($) son importantes. El acento circunejo signica que requiere que el patrn concuerde con el inicio de la cadena de caracteres, y el signo de dlar signica que exige que el patrn concuerde con el n de la cadena. Este concepto se explica mejor con un ejemplo. Si hubiramos utilizado el patrn ^time/ (sin el signo de dlar al nal), entonces cualquier URL que comience con time/ concordara, as como /time/foo y /time/bar, no slo /time/. Del mismo modo, si dejamos de lado el carcter acento circunejo inicial (time/$), Django concordara con cualquier URL que termine con time/, as como /foo/bar/time/. Por lo tanto, usamos tanto el acento circunejo como el signo de dlar para asegurarnos que slo la URL /time/ concuerde. Nada ms y nada menos. Quizs te preguntes qu pasa si alguien intenta acceder a /time. Esto es manejado como esperaras (a travs de un redireccionamiento) siempre y cuando APPEND_SLASH tenga asignado el valor True. (Vese el Apndice E para una buena lectura sobre este tema). Para probar nuestro cambios en la URLconf, inicia el servidor de desarrollo de Django, como hiciste en el Captulo 2, ejecutando el comando python manage.py runserver. (Si ya lo tenas corriendo, est bien tambin. El servidor de desarrollo automticamente detecta los cambios en tu cdigo de Python y recarga de ser necesario, as no tienes que reiniciar el servidor al hacer cambios). El servidor est corriendo en la direccin http://127.0.0.1:8000/, entonces abre tu navegador web y ve a http://127.0.0.1:8000/time/. Deberas ver la salida de tu vista de Django. Enhorabuena! Has creado tu primera pgina Web hecha con Django. Expresiones Regulares: Las Expresiones Regulares (o regexes) son la forma compacta de especicar patrones en un texto. Aunque las URLconfs de Django permiten el uso de regexes arbitrarias para tener un potente sistema de denicin de URLs, probablemente en la prctica no utilices ms que un par de patrones regex. Esta es una pequea seleccin de patrones comunes: Smbolo . (punto) \d [A-Z] [a-z] [A-Za-z] + [^/]+ * {1,3} Coincide con Cualquier carcter Cualquier dgito Cualquier carcter, A-Z (maysculas) Cualquier carcter, a-z (minsculas) Cualquier carcter, a-z (no distingue entre mayscula y minscula) Una o ms ocurrencias de la expresin anterior (ejemplo, \d+ coincidir con uno o ms dgitos) Todos los caracteres excepto la barra. Cero o ms ocurrencias de la expresin anterior (ejemplo, \d* coincidir con cero o ms dgitos) Entre una y tres (inclusive) ocurrencias de la expresin anterior regulares, mira el mdulo

Para ms informacin acerca de las expresiones http://www.djangoproject.com/r/python/re-module/.

4.3 Cmo procesa una peticin DjangoDebemos sealar varias cosas en lo que hemos visto. Este es el detalle de lo que sucede cuando ejecutas el servidor de desarrollo de Django y hacemos una peticin a una pgina Web. El comando python manage.py runserver importa un archivo llamado settings.py desde el mismo directorio. Este archivo contiene todo tipo de conguraciones opcionales para esta instancia de Django en particular, pero una de las conguraciones ms importantes es ROOT_URLCONF. La variable ROOT_URLCONF le dice a Django qu mdulo de Python debera usar para la URLconf de este sitio Web. Recuerdas cuando django-admin.py startproject cre el archivo settings.py y urls.py? Bueno, el settings.py generado automticamente tena un ROOT_URLCONF que

apunta al urls.py generado automticamente. Qu conveniente! Cuando llega una peticin digamos, una peticin a la URL /time/ Django carga la URLconf apuntada por la variable ROOT_URLCONF. Luego comprueba cada uno de los patrones de URL en la URLconf en orden, comparando la URL solicitada con un patrn a la vez, hasta que encuentra uno que coincida. Cuando encuentra uno que coincide, llama a la funcin de vista asociada con ese patrn, pasando un objeto HttpRequest como primer parmetro de la funcin. (Veremos ms de HttpRequest luego). La funcin de vista es responsable de retornar un objeto HttpResponse. Conoces ahora lo bsico sobre cmo hacer pginas Web con Django. Es muy sencillo, realmente slo tenemos que escribir funciones de vista y relacionarlas con URLs mediante URLconfs. Podras pensar que es lento enlazar las URL con funciones usando una serie de expresiones regulares, pero te sorprenders.

4.3.1 Cmo procesa una peticin Django: Detalles completosAdems del mapeo directo de URLs con funciones vista que acabamos de describir, Django nos provee un poco ms de exibilidad en el procesamiento de peticiones. El ujo tpico resolucin de URLconf a una funcin de vista que retorna un HttpResponse puede ser corto-circuitado o *augmented* mediante middleware. Los secretos del middleware sern tratados en profundidad en el Captulo15, pero un esquema (ver Figura 3-1) te ayudar conceptualmente a poner todas las piezas juntas.

4.3. Cmo procesa una peticin Django

Figura 3-1: El ujo completo de un peticin y una respuesta Django. Cuando llega una peticin HTTP desde el navegador, un manejador especco a cada servidor construye la HttpRequest, para pasarla a los componentes y maneja el ujo del procesamiento de la respuesta. El manejador luego llama a cualquier middleware de Peticin o Vista disponible. Estos tipos de middleware son tiles para *augmenting* los objetos HttpRequest as como tambin para proveer manejo especial a determinados tipos de peticiones. En el caso de que alguno de los mismos retornara un HttpResponse la vista no es invocada. Hasta a los mejores programadores se le escapan errores (bugs), pero el middleware de excepcin ayuda a aplastarlos. Si una funcin de vista lanza una excepcin, el control pasa al middleware de Excepcin. Si este middleware no retorna un HttpResponse, la excepcin se vuelve a lanzar. Sin embargo, no todo est perdido. Django incluye vistas por omisin para respuestas amigables a errores 404 y 500.

Finalmente, el middleware de respuesta es bueno para el procesamiento posterior a un HttpResponse justo antes de que se enve al navegador o haciendo una limpieza de recursos especcos a una peticin.

4.4 URLconfs y el acoplamiento dbilAhora es el momento de resaltar una parte clave de losofa detrs de las URLconf y detrs de Django en general: el principio de acoplamiento dbil (loose coupling). Para explicarlo simplemente, el acoplamiento dbil es una manera de disear software aprovechando el valor de la importancia de que se puedan cambiar las piezas. Si dos piezas de cdigo estn dbilmente acopladas (loosely coupled) los cambios realizados sobre una de dichas piezas va a tener poco o ningn efecto sobre la otra. Las URLconfs de Django son un claro ejemplo de este principio en la prctica. En una aplicacin Web de Django, la denicin de la URL y la funcin de vista que se llamar estn dbilmente acopladas; de esta manera, la decisin de cul debe ser la URL para una funcin, y la implementacin de la funcin misma, residen en dos lugares separados. Esto permite el desarrollo de una pieza sin afectar a la otra. En contraste, otras plataformas de desarrollo Web acoplan la URL con el programa. En las tpicas aplicaciones PHP (http://www.php.net/), por ejemplo, la URL de tu aplicacin es designada por dnde colocas el cdigo en el sistema de archivos. En versiones anteriores del framework Web Python CherryPy (http://www.cherrypy.org/) la URL de tu aplicacin corresponda al nombre del mtodo donde resida tu cdigo. Esto puede parecer un atajo conveniente en el corto plazo, pero puede tornarse inmanejable a largo plazo. Por ejemplo, consideremos la funcin de vista que escribimos antes, la cul nos mostraba la fecha y la hora actual. Si quieres cambiar la URL de tu aplicacin digamos, mover desde /time a /currenttime/ puedes hacer un rpido cambio en la URLconf, sin preocuparte acerca de la implementacin subyacente de la funcin. Similarmente, si quieres cambiar la funcin de vista alterando la lgica de alguna manera puedes hacerlo sin afectar la URL a la que est asociada tu funcin de vista. Adems, si quisiramos exponer la funcionalidad de fecha actual en varias URL podramos hacerlo editando el URLconf con cuidado, sin tener que tocar una sola lnea de cdigo de la vista. Eso es el acoplamiento dbil en accin. Continuaremos exponiendo ejemplos de esta importante losofa de desarrollo a lo largo del libro.

4.5 Errores 404En las URLconf anteriores, hemos denido un solo patrn URL: el que maneja la peticin para la URL /time. Qu pasara si se solicita una URL diferente? Para averiguarlo, prueba ejecutar el servidor de desarrollo Django e intenta acceder a una pgina Web como http://127.0.0.1:8000/hello/ o http://127.0.0.1:8000/does-not-exist/, o mejor como http://127.0.0.1:8000/ (la raz del sitio). Deberas ver el mensaje Page not found (ver la Figura 3-2). (Es linda, no? A la gente de Django seguro le gustan los colores pasteles). Django muestra este mensaje porque solicitaste una URL que no est denida en tu URLconf.

4.4. URLconfs y el acoplamiento dbil

Figura 3-2. Pgina 404 de Django La utilidad de esta pgina va ms all del mensaje bsico de error 404; nos dice tambin, qu URLconf utiliz Django y todos los patrones de esa URLconf. Con esa informacin, tendramos que ser capaces de establecer porqu la URL solicitada lanz un error 404. Naturalmente, esta es informacin importante slo destinada a ti, el administrador Web. Si esto fuera un sitio en produccin alojado en Internet, no quisiramos mostrar esta informacin al pblico. Por esta razn, la pgina Page not found es slo mostrada si nuestro proyecto en Django est en modo de depuracin (debug mode). Explicaremos cmo desactivar este modo ms adelante. Por ahora, slo diremos que todos los proyectos estn en modo de depuracin cuando los creamos, y si el proyecto no lo estuviese, se retornara una respuesta diferente.

4.6 Tu segunda Vista: URLs dinmicasEn la primer vista de ejemplo, el contenido de la pgina la fecha/hora actual eran dinmicas, pero la URL (/time) era esttica. En la mayora de las aplicaciones Web, sin embargo, la URL contiene parmetros que inuyen en la salida de la pgina. Vamos a crear una segunda vista que nos muestre la fecha y hora actual con un adelanto de ciertas horas. El objetivo es montar un sitio en la que la pgina /time/plus/1/ muestre la fecha/hora una hora ms adelantada, la pgina /time/plus/2/ muestre la fecha/hora dos horas ms adelantada, la pgina /time/plus/3/ muestre la fecha/hora tres horas ms adelantada, y as. A un novato se le ocurrira escribir una funcin de vista distinta para cada adelanto de horas, lo que resultara una URLconf como esta:urlpatterns = patterns( , ( r ^time/$ , current_datetime), ( r ^time/plus/1/$ , one_hour_ahead), ( r ^time/plus/2/$ , two_hours_ahead), ( r ^time/plus/3/$ , three_hours_ahead),

( r ^time/plus/4/$ , four_hours_ahead), )

Claramente, esta lnea de pensamiento es incorrecta. No slo porque producir redundancia entre las funciones de vista, sino tambin la aplicacin estar limitada a admitir slo el rango horario denido uno, dos, tres o cuatro horas. Si, de repente, quisiramos crear una pgina que mostrara la hora cinco horas adelantada, tendramos que crear una vista distinta y una lnea URLconf, perpetuando la duplicacin y la demencia. Aqu necesitamos algo de abstraccin.

4.6.1 Algunas palabras acerca de las URLs bonitasSi tienes experiencia en otra plataforma de diseo Web, como PHP o Java, es posible que ests pensado, Oye, usemos un parmetro cadena de consulta!, algo como /time/plus?hours=3, en la cual la hora ser designada por el parmetro hours de la cadena de consulta de la URL (la parte a continuacin de ?). Con Django puedes hacer eso (pero te diremos cmo ms adelante, si es que realmente quieres saberlo), pero una de las losofas del ncleo de Django es que las URLs deben ser bonitas. La URL /time/plus/3 es mucho ms limpia, ms simple, ms legible, ms fcil de dictarse a alguien y . . . justamente ms bonita que su homloga forma de cadena de consulta. Las URLs bonitas son un signo de calidad en las aplicaciones Web. El sistema de URLconf que usa Django estimula a generar URLs bonitas, haciendo ms fcil el usarlas que el no usarlas.

4.6.2 Comodines en los patrones URLContinuando con nuestro ejemplo hours_ahead, pongmosle un comodn al patrn URL. Como ya se mencion antes, un patrn URL es una expresin regular; de aqu, es que usamos el patrn de expresin regular \d+ para que coincida con uno o ms dgitos:from django.conf.urls.defaults import * from mysite.views import current_datetime, hours_ahead urlpatterns = patterns( , ( r ^time/$ , current_datetime), ( r ^time/plus/ \ d+/$ , hours_ahead), )

Este patrn coincidir con cualquier URL que sea como /time/plus/2/, /time/plus/25/, o tambin /time/plus/100000000000/. Ahora que lo pienso, podemos limitar el lapso mximo de horas en 99. Eso signica que queremos tener nmeros de uno o dos dgitos en la sintaxis de las expresiones regulares, con lo que nos quedara as \d{1,2}:( r ^time/plus/ \ d{1,2}/$ , hours_ahead),

Nota: Cuando construimos aplicaciones Web, siempre es importante considerar el caso ms descabellado posible de entrada, y decidir si la aplicacin admitir o no esa entrada. Aqu hemos limitado a los exagerados reconociendo lapsos de hasta 99 horas. Y, por cierto, Los Limitadores exagerados, aunque largo, sera un nombre fantstico para una banda musical. Ahora designaremos el comodn para la URL, necesitamos una forma de pasar esa informacin a la funcin de vista, as podremos usar una sola funcin de vista para cualquier adelanto de hora. Lo haremos colocando parntesis alrededor de los datos en el patrn URL que querramos guardar. En el

4.6. Tu segunda Vista: URLs dinmicas

caso del ejemplo, queremos guardar cualquier nmero que se anotar en la URL, entonces pongamos parntesis alrededor de \d{1,2}:( r ^time/plus/( \ d{1,2})/$ , hours_ahead),

Si ests familiarizado con las expresiones regulares, te sentirs como en casa aqu; estamos usando parntesis para capturar los datos del texto que coincide. La URLconf nal, incluyendo la vista anterior current_datetime, nos quedar algo as:from django.conf.urls.defaults import * from mysite.views import current_datetime, hours_ahead urlpatterns = patterns( , ( r ^time/$ , current_datetime), ( r ^time/plus/( \ d{1,2})/$ , hours_ahead), )

Con cuidado, vamos a escribir la vista hours_ahead. Orden para programar En este ejemplo, primero escribimos el patrn URL y en segundo lugar la vista, pero en el ejemplo anterior, escribimos la vista primero y luego el patrn de URL. Qu tcnica es mejor? Bien, cada programador es diferente. Si eres del tipo de programadores que piensan globalmente, puede que tenga ms sentido que escribas todos los patrones de URL para la aplicacin al mismo tiempo, al inicio del proyecto, y despus el cdigo de las funciones de vista. Esto tiene la ventaja de darnos una lista de objetivos clara, y es esencial denir los parmetros requeridos por las funciones de vista que necesitaremos desarrollar. Si eres del tipo de programadores que les gusta ir de abajo hacia arriba, tal vez preeras escribir las funciones de vista primero, y luego asociarlas a URLs. Esto tambin est bien. Al nal, todo se reduce a elegir qu tcnica se amolda ms a tu cerebro. Ambos enfoques son vlidos. hours_ahead es muy similar a current_datetime, vista que escribimos antes, slo que con una diferencia: tomar un argumento extra, el nmero de horas que debemos adelantar. Agrega al archivo views.py lo siguiente:import django.http.HttpResponse import datetime def hours_ahead(request, offset): offset = int(offset) dt = datetime.datetime.now() + datetime.timedelta(hours=offset) html = " In %s hour(s), it will be %s . " % (offset, dt) return HttpResponse(html)

Repasemos el cdigo anterior lnea a lnea: Tal como hicimos en la vista current_datetime, django.http.HttpResponse y el mdulo datetime. importamos la clase

La funcin de vista hours_ahead, toma dos parmetros: request y offset. request es un objeto HttpRequest, al igual que en current_datetime. Lo diremos nuevamente: cada vista siempre toma un objeto HttpRequest como primer parmetro. offset es la cadena de caracteres capturada por los parntesis en el patrn URL. Por ejemplo, si la peticin URL fuera /time/plus/3/, entonces el offset debera ser la cadena de caracteres 3. Si la peticin URL fuera /time/plus/21/, entonces el offset debera ser la cadena de caracteres 21. Notar que la cadena de caracteres capturada siempre es una cadena de caracteres, no un entero, incluso si se compone slo de dgitos, como en el caso 21. 24 Captulo 4. Captulo 3: Los principios de las pginas Web dinmicas

Decidimos llamar a la variable offset, pero puedes asignarle el nombre que quieras, siempre que sea un identicador vlido para Python. El nombre de la variable no importa; todo lo que importa es lo que contiene el segundo parmetro de la funcin (luego de request). Es posible tambin usar una palabra clave, en lugar de posicin, como argumentos en la URLconf. Eso lo veremos en detalle en el Captulo 8. Lo primero que hacemos en la funcin es llamar a int() sobre offset. Esto convierte el valor de la cadena de caracteres a entero. Tener en cuenta que Python lanzar una excepcin ValueError si se llama a la funcin int() con un valor que no puede convertirse a un entero, como lo sera la cadena de caracteres foo. Sin embargo, en este ejemplo no debemos preocuparnos de atrapar la excepcin, porque tenemos la certeza que la variable offset ser una cadena de caracteres conformada slo por dgitos. Sabemos esto, por el patrn URL de la expresin regular en el URLconf (\d{1,2}) captura slo dgitos. Esto ilustra otra ventaja de tener un URLconf: nos provee un primer nivel de validacin de entrada. La siguiente lnea de la funcin muestra la razn por la que se llam a la funcin int() con offset. En esta lnea, calculamos la hora actual ms las hora que tiene offset, almacenando el resultado en la variable dt. La funcin datetime.timedelta requiere que el parmetro hours sea un entero. A continuacin, construimos la salida HTML de esta funcin de vista, tal como lo hicimos en la vista current_datetime. Una pequea diferencia en esta lnea, es que usamos el formato de cadenas de Python con dos valores, no slo uno. Por lo tanto, hay dos smbolos %s en la cadena de caracteres y la tupla de valores a insertar sera: (offset, dt). Finalmente, retornamos el HttpResponse del HTML de nuevo, tal como hicimos en la vista current_datetime. Con esta funcin de vista y la URLconf escrita, ejecuta el servidor de desarrollo de Django (si no est corriendo), y visita http://127.0.0.1:8000/time/plus/3/ para vericar que lo que hicimos funciona. Luego prueba http://127.0.0.1:8000/time/plus/5/. Para terminar visita http://127.0.0.1:8000/time/plus/100/ para vericar que el patrn en la URLconf slo acepta nmero de uno o dos dgitos, Django debera mostrar un error en este caso como Page not found, tal como vimos en la seccin Errores 404 anteriormente. La URL http://127.0.0.1:8000/time/plus/ (sin horas designadas) debera tambin mostrar un error 404. Si ests siguiendo el libro y programando al mismo tiempo, notars que el archivo views.py ahora contiene dos vistas. (Omitimos la vista current_datetime del ejemplo anterior slo por claridad). Ponindolas juntas, veramos algo similar a esto:from django.http import HttpResponse import datetime def current_datetime(request): now = datetime.datetime.now() html = " It is now return HttpResponse(html)

%s . " % now

def hours_ahead(request, offset): offset = int(offset) dt = datetime.datetime.now() + datetime.timedelta(hours=offset) html = " In %s hour(s), it will be %s . " % (offset, dt) return HttpResponse(html)

4.7 Pginas de error bonitas con DjangoTommonos un momento para admirar la bonita aplicacin web que hemos creado hasta ahora . . . y ahora rompmosla! Introduzcamos deliberadamente un error de Python en el archivo views.py comentando la lnea offset = int(offset) de la vista hours_ahead:

4.7. Pginas de error bonitas con Django

def hours_ahead(request, offset): #offset = int(offset) dt = datetime.datetime.now() + datetime.timedelta(hours=offset) html = " In %s hour(s), it will be %s . " % (offset, dt) return HttpResponse(html)

Ejecuta el servidor de desarrollo y navega a /time/plus/3/. Vers una pgina de error con mucha informacin signicativa, incluyendo el mensaje TypeError mostrado en la parte superior de la pgina: nsupported type for timedelta hours component: str". Qu ha ocurrido? Bueno, la funcin datetime.timedelta espera que el parmetro hours sea un entero, y hemos comentado la lnea de cdigo que realiza la conversin del offset a entero. Eso causa que datetime.timedelta lance un TypeError. Es el tpico pequeo bug que todo programador comete en algn momento. El punto de este ejemplo fue demostrar la pgina de error de Django. Dediquemos un momento a explorar esta pgina y descubrir las distintas piezas de informacin que nos brinda. Aqu comentamos algunas cosas a destacar: En la parte superior de la pgina se muestra la informacin clave de la excepcin: el tipo y cualquier parmetro de la excepcin (el mensaje nsupported type" en este caso), el archivo en el cul la excepcin fue lanzada, y el nmero de lnea que contiene el error. Abajo de la informacin clave de la excepcin, la pgina muestra el *traceback* de Python para dicha excepcin. Este es el *traceback* estndar que se obtiene en el interprete de Python, slo que ms interactivo. Por cada marco de la pila, Django muestra el nombre del archivo, el nombre de la funcin/mtodo, el nmero de lnea, y el cdigo fuente de esa lnea. Haz click en la lnea de cdigo (en gris oscuro) para ver varias lneas anteriores y posteriores a la lnea errnea, lo que nos brinda un poco de contexto. Haz click en Locals vars debajo de cualquier marco de la pila para ver la tabla de todas las variables locales y sus valores, en ese marco y en la posicin exacta de cdigo en el cual fue lanzada la excepcin. Esta informacin de depuracin es invaluable. Nota el texto Switch to copy-and-paste view debajo de la cabecera Traceback. Haz click en esas palabras, y el *traceback* cambiar a una versin que te permitir fcilmente copiar y pegar. Usando esto para cuando necesitemos compartir el traceback de la excepcin con otros para obtener soporte tcnico como los amables colegas que encontraremos en el canal de IRC o la lista de correo de Django. A continuacin, la seccin Request information incluye una gran cantidad de informacin sobre la peticin Web que provoc el error: informacin GET y POST, valores de las cookies y meta informacin como las cabeceras CGI. El Apndice H es una completa referencia sobre toda la informacin que contienen los objetos peticiones. Ms abajo, la seccin Settings lista la conguracin de la instalacin de Django en particular. El Apndice E, cubre en detalle los ajustes de conguracin disponibles. Por ahora, slo mira los ajustes para tener una idea de la informacin disponible. La pgina de error de Django es capaz de mostrar ms informacin en ciertos casos especiales, como por ejemplo, en el caso de error de sintaxis en las plantillas. Lo abordaremos ms tarde, cuando discutamos el sistema de plantillas de Django. Por ahora, quita el comentario en la lnea offset = int(offset) para que la funcin de vista funcione normalmente de nuevo. Eres el tipo de programador al que le gusta depurar con la ayuda de sentencias print cuidadosamente colocadas? Puedes usar la pgina de error de Django para hacer eso sin la sentencia print. En cualquier punto de la vista, temporalmente podemos insertar un assert False para provocar una pgina de error. Luego, podremos ver las variables locales y el estado del programa. (Hay maneras ms avanzadas de depurar las vista en Django, lo explicaremos ms adelante, pero esto es la forma ms rpida y fcil). Finalmente, es obvio que la mayor parte de la informacin es delicada expone las entraas del cdigo fuente de Python, como tambin de la conguracin de Django y sera una estupidez mostrarla al 26 Captulo 4. Captulo 3: Los principios de las pginas Web dinmicas

pblico en Internet. Una persona con malas intenciones podra usar esto para intentar aplicar ingeniera inversa en la aplicacin Web y hacer cosas maliciosas. Por esta razn, la pgina de error es mostrada slo cuando el proyecto est en modo depuracin. Explicaremos cmo desactivar este modo ms adelante. Por ahora, hay que tener en claro que todos los proyectos de Django estn en modo depuracin automticamente cuando son creados. (Suena familiar? Los errores Page not found, descriptos en la seccin Errores 404, trabajan de manera similar.)

4.8 Qu sigue?Hasta ahora hemos producido las vistas mediante cdigo HTML dentro del cdigo Python. Desafortunadamente, esto es casi siempre es una mala idea. Pero por suerte, con Django podemos hacer esto con un potente motor de plantillas que nos permite separar el diseo de las pginas del cdigo fuente subyacente. Nos sumergiremos en el motor de plantillas de Django en el prximo capitulo

4.8. Qu sigue?

CAPTULO 5

Captulo 4: El sistema de plantillas de Django

En el captulo anterior, quizs notaste algo extrao en cmo retornbamos el texto en nuestras vistas de ejemplos. A saber, el HTML fue codicado 1 directamente en nuestro cdigo Python. Este convenio conduce a problemas severos: Cualquier cambio en el diseo de la pgina requiere un cambio en el cdigo de Python. El diseo de un sitio tiende a cambiar ms frecuentemente que el cdigo de Python subyacente, por lo que sera conveniente si el diseo podra ser cambiado sin la necesidad de modicar el cdigo Python. Escribir cdigo Python y disear HTML son dos disciplinas diferentes, y la mayora de los entornos de desarrollo web

Django, La Guia Definitiva

Documents

plantillas y ltros5

plantillas personalizados

plantillas incorporadas11

administracin django

datos en

usar vistas genricas

instalar django

urlconfs y