Hoy después de comer y de dormirme una siestita, como corresponde, salí de mi casa caminando con destino al centro de la ciudad. En realidad, a un lugar cercano al parque (perdón, quise dibujar un Google Maps, pero no me deja hacer las rayas sobre las calles sin respetar las manos de las mismas, una cagada: ¿cómo le decís que vas a pié?) y fui tomando fotografías de los paisajes por los que cruzaba.

Además iba pensando en que uno que vive en Paraná y que nació acá, no se da cuenta que hay lugares que son hermosos realmente porque está acostumbrado a verlos todos los días, pero cuando ve las fotos de estos, se da cuenta de lo lindos que son.

Acá dejo el Álbum de Picasa Web completo para que puedan ver las demás fotos.

¿Qué somos nosotros? ¿Clientes, personas, gente que trabaja para pagar lo que consume, números, bytes, bits, simplemente una bola de masa que destruye el planeta?

Bueno, sí. Después de unos cuantos años de vida uno se empieza a preguntar: ¿para qué estamos? ¿de dónde venimos? ¿hacia dónde vamos?.

Normalmente, en la secundaria, este tema es tratado en algún punto no muy profundo y todas las respuestas son complicadas, maravillosas y confusas. Personalmente yo creo que todas las respuestas son una mierda ya que no somos nosotros quienes deciden por nosotros: en lo que hacemos, en lo que pensamos y quizás hasta en lo que sentimos. Todo, absolutamente todo está influenciado por alguien, por algunos, o por todos. Pero principalmente por "algunos".

Hoy, 13 de Septiembre del 2010, me pasé toda la mañana en las oficinas de la EPE (Empresa Provincial de Energía), en otras palabras: son los que tienen el Monopolio Energético en la Ciudad de Santa Fe y por lo tanto quienes brindan la llamada "luz eléctrica" por la gente común.

No quiero decir que se interprete mal que pasé toda la mañana como una exageración, pero sinceramente, estuve desde las 10am hasta las 13:30hs o un poquito más. Entonces, me corrijo, estuve dos horas de la mañana y una hora y media de la siesta, mediodía, o tarde, como sea.

A todo, ¿qué pasaba? ¿cuál era el motivo de mi visita a estas hermosas oficinas?: me estaban choreando. Claro, uno piensa que cuando le chorean debe ir a la policía a reclamar, denunciar y que cuando agarren al delincuente vaya preso y cumpla su condena, ¿no?. Lamentablemente esto sólo pasa en las películas de Hollywood y quizás en algunas otras que no he visto, pero acá no.

Todo se remonta a hace unos cuantos años atrás, por lo menos 4. Para ese entonces "yo vivía en el bosque muy contento": con mi hermano en un departamento en Santa Fe ubicado en calle Corrientes. Haciéndonos pasar como estudiantes y esas cosas que uno dice y hace para vivir sólo lejos del alcance de su madre, compartíamos los gastos generales. Como ser, luz, gas, agua, alquiler, comida y demás.

"Pero un día llegó el hombre con sus jaulas": eso, fueron algunos choros a mi edificio y me chorearon el medidor, "lo encerraron y lo llevaron a la ciudad". Hará 2 años y medio de esto. Pero claro, ¿cómo nos dimos cuenta de eso?: hicimos un reclamo a la EPE cerca de esa fecha porque notábamos que nos estaba viniendo un exceso en el consumo de luz. Pensábamos que no podía ser que siendo dos pobres muchachos de pelo corto, sucios y con dos computadoras encendidas todo el día, consumamos tanto: algo así como $150 por bimestre.

Entonces, el "inspector amigo" de la EPE nos dijo: "Chango, te han robao el medidor y les han emparchao los cables directos". Le pedimos por favor que no nos corte la luz porque seguro que iban a demorar un montón en venir a reparar eso y por lo tanto íbamos a estar sin luz por todo ese tiempo. Sospechosamente... aceptó.

Lo que teníamos que teníamos que hacer con mi hermano era ir a la comisaría y hacer la denuncia para que quede constancia de este robo y luego ir a las oficinas (en las que me pasé otra mañana como la de hoy en aquel entonces... al pedo) con esa constancia y pedir la reconexión del medidor.

Por una razón u otra, nos colgamos una semana por lo menos en ir a hacer la denuncia. Una vez había ido yo con un amigo, pero nos hicieron esperar un rato, me tomaron la declaración, me hicieron esperar como una 1 hora más, me hicieron declarar otra vez adelante de otra persona y después de eso estuvimos esperando 1 hora más hasta que nos cansamos (y además teníamos que ir a cursar) y nos fuimos a la mierda: digo, la facu.

Pero... ¿qué pasó? Eh! ¿qué pasó?. Luego de esa semana de cuelgue nos llegó una factura de la EPE indicando que teníamos que pagar un monto similar a los meses anteriores y dijimos: "¿Cómo? Si no tenemos medidor". Nos fuimos a fijar si estaba el medidor y no estaba. Después, nos fijamos en la factura y efectivamente la lectura del medidor había sido un día en el que el medidor no estaba. WTF?

Consulté con amigo "X" que alguna vez trabajó en la EPE y me dijo: "Los tipos estos que toman la medida (me dijo el nombre de ellos, pero no recuerdo): ¿sabés lo que hacen?. Ellos van por varios meses a tu casa, calculan más o menos cuanto consumís y de ahí hace un promedio, y a veces un poco más y a veces un poco menos, basándose en años anteriores, y después ya no van más a tu casa, en cambio se van a un bar a tomarse un par de birras o se vuelven a la casa a estar con la flia o lo que se te ocurra"

"Naaah!!". Fue lo primero que dije, y después me puse a pensar que posta podía ser, que no era tan descabellado y que todo cerraba. Yo no tenía medidor y tenía una lectura tomada en un día en el que no tenía medidor. Era buenísimo!.

Pasó un tiempo más (meses - llegaron muchas facturas en el medio, incluso una de $550), junté fuerza y ganas. Hice la denuncia en la policía, la llevé a la EPE, me comí el garrón de perder toda la mañana ahí y me planté firme: "Esto no te lo pago ni en pedo". Hablé un montón sobre esto y me dijeron que tenía razón y que estaba bien que no lo pague a eso y que dentro de un par de días me iban a hacer la reconexión del medidor.

Pasó otro tiempo más y fueron a hacer la reconexión del medidor y todos felices, o al menos eso era lo que todos pensábamos. Siguió pasando el tiempo, meses, y siguieron viniendo facturas de $200o $250. Empezamos a pensar que nos estaban cagando otra vez y que todo era una gran mentira de la cuál no podíamos salir y que tampoco teníamos muchos recursos para usar, no sabíamos que hacer y el tiempo pasaba. Tampoco teníamos mucho tiempo en ese entonces para seguir perdiendo mañanas y mañanas en la EPE o en el lugar que sea.

El tiempo siguió pasando, tanto que mi hermano se fue del departamento y vino a vivir conmigo una amiga. Seguimos pagando las facturas y diciendo: "La puta madre, no puede ser que cada dos meses venga entre 200 y 250 pesos siendo que nos vamos los fines de semana y que a veces no estamos por semanas enteras".

Llegamos al verano de este años, los dos nos fuimos por 2 o 3 meses del departamento y bajamos la llave del disyuntor cosa de nuestra casa no consuma nada, así también cerramos el agua y el gas. Onda: "no hay nadie" :)

¿Qué pasó? Cuando volvimos al departamento nos encontramos con la factura que decía: "Usted tiene que pagar $250". Culiado, ¿cómo puede ser?. Otra vez, como siempre, siguió pasando el tiempo y siguió pasando y pasando hasta hace una semana atrás que mi compañera de departamento me llama y me comenta que tenía novedades sobre el tema de la EPE.

Me comentó que llamó a un electricista matriculado para ver si había alguna pérdida de energía por algún lado y si era eso lo que había que paguemos tanto. El tipo este comprobó que no había pérdida y que todo funcionaba correctamente. Además hizo una nota diciendo que con los electrodomésticos que teníamos no podía ser que consumamos esa cantidad de KWs. La firmó y la dejó para que vayamos a reclamar a la EPE.

Mi compañera fue y le mandaron un inspector para corroborar esto que decía el Electricista. El tipo fue y le dijo "Sí, es culpa nuestra. El medidor que está registrado como que es de ustedes es el del departamento de abajo y el que realmente es el de ustedes no está registrado en ningún lado. Ese medidor no le corresponde a nadie: no existe."

Y bueno, señores y señoras: le estábamos pagando la luz a la vecina de abajo que, casualmente, se había mudado hacía un par de semanas, con lo cuál no podíamos ir a preguntarle cuánto pagaba (si pagaba) de luz y verificar con su factura que era lo que le estaban cobrando.

El inspector este de la EPE quedó en comunicarse con mi compañera e informarle que era lo que tenía que hacer y demás. Pasaron un par de días y el tipo la llamó, le dió sus datos, y le dijo que vaya a reclamar por este tema a las oficinas de la EPE diciendo que iba de parte de él (nombre y número de inspector de la EPE).

Y acá quería llegar: hoy fuimos. Me levanté temprano y me fui para Santa Fe a encontrarme con mi compañera, hablar un rato al pedo antes, ponernos de acuerdo, que me explique bien qué era lo que había pasado, como se dieron las cosas, charlar al pedo sobre cualquier cosa y que nos pongamos firmes reclamando lo que nos corresponde.

Explicamos lo mejor que podíamos lo que había ocurrido y el tipo siempre intentaba buscar la forma de que sea culpa del consorcio del edificio o bien de la inmobiliaria por no tener los medidores visibles y ordenados y que blah blah blah. Nos tiraba la pelota a nosotros siempre que podía. Incluso diciendo que los medidores estaban en el lugar correcto pero que las conexiones internas del edificio estaban cruzadas y que eso no era responsabilidad de la EPE.

El tipo este (José) nos dijo que él mismo, o su jefe, iban a ir personalmente a comprobar qué era exactamente lo que estaba pasando porque el inspector que fue aquella vez no había dejado ningún registro en el sistema e inlcuso figuraba como "Pendiente" su inspección. Tampoco lo pudieron ubicar por teléfono por ningún lado, pero al menos el nombre era real y trabajaba en la EPE :P

Además nos dijo que en "el sistema" le figuraba que "la de abajo" no había pagado nunca una factura de energía. Ídola!

Nos fuimos lo más rápido que pudimos para el departamento porque sospechábamos que ya iba a estar la camionetita de la EPE ahí acomodando todo para que "sea culpa nuestra o de alguien a excepción de ellos" acomodando, o mejor dicho, des-acomodándolos. La idea de esto era sacar un par de fotos para que quede constancia de que "nos estaban cagando", que los medidores estaban perfectamente ubicados y legibles y que la factura estaba cobrando cualquier cosa y no se correspondía con lo que nosotros deberíamos pagar.

Acá van las fotos del medidor:

Esta es una de las facturas que por algún motivo vino menos de $200. Pero no importa, lo que quiero mostrar acá es el número de medidor que tenemos registrados como "nuestro" en la factura. Lo que hice fue borrar los datos del titular y resaltar el lugar dónde hay que mirar el número del medidor que es: 578150.

En esta foto muestro el tablero que contiene todos los medidores que corresponden al edificio en el que alquilo un departamento. Lo que resalté en verde son dos medidores normales (de otros departamentos) con su respectivo número de departamento. Para que se note cómo se lee el tablero que estoy mostrando. Esto es, el número del departamento al que corresponde ese medidor está por encima de este. ¿Se entiende o hay que ser super-dotado?

Además marqué en amarillo el medidor que del departamento 12 (a quién le estamos pagando la luz hace unos años ya) y en rojo nuestro medidor. Lo que se puede ver ahí es que "se presta a confusión" si uno mira rápido el tablero ya que el número 22 (que es mí departamento) está muy pegado al medidor del 12, entonces puede ser que el chango que va a tomar la lectura anote el de ese en vez del que me corresponde a mí.

Pero para ser más, si uno mira la foto haciendo mucho zoom, puede notar que el medidor que corresponde al departamento 12 tiene el número de medidor que nosotros estamos pagando en la factura, osea, está bien que el lector tome esa medida cuando va (ya que tiene el número de medidor que corresponde). Pero claro, ¿cómo el tipo no va a avisar que hay una inconsistencia en todo esto?

Además, el tipo que nos hizo la reconexión y puso el medido que está dentro del recuadro rojo, ¿también se equivocó y anotó el número del medidor que es del 12? Osea, ¿llevó y colocó un medidor que automáticamente perdió de vista y anotó uno que no era? ¿qué onda? ¿cómo se explica todo esto?

¿Qué más hay además de respuestas filosóficas como nos vienen dando y tirar la pelota para cualquier lado como sea?

Es la primera vez que voy a hacer esto, no estoy seguro porqué se me ocurrió en este momento, pero ya lo había visto en el blog de Juanjo hace un tiempo aunque no le dí mucha bola y ahora que me surgió la idea nuevamente, me acordé que ya lo había visto y que la idea no era mía :P

Voy a intentar dar la charla por mi blog, para todos los que alguna vez la quisieron ver y no tuvieron la oportunidad o ya han ido y se quedaron con dudas, o simplemente para los que les interese :)

Voy a ir mostrando cada una de las diapositivas y tratando de escribir lo que debería decir en cada una de ellas, aunque no estoy seguro si va a quedar lindo, vamos a probar a ver que pasa.

Para ir rompiendo el hielo de "cómo hacer esto"... Mi nombre es Manuel Kaufmann, quizás más conocido como "humitos". Pertenezco a PyAr hace unos años ya y estoy muy contento de eso. Hoy voy a dar una charla introductoria sobre Django ya que me parece una herramienta muy poderosa, sencilla y amigable, entre otras cosas, para los desarrolladores webs.

La idea de esta charla es hacer un recorrido sobre las funciones básicas de Django, creando un proyecto desde cero y obteniendo como resultado final un blog muy simple, si es que se lo puede llamar así. Vamos a ver características básicas que se utilizan en todo momento del desarrollo y quizás que se olvidan con frecuencia.

Charlaremos algunos conceptos teóricos básicos de cómo está construido Django y porqué es así y luego haremos una parte práctica en dónde programaremos "juntos" si se quiere un blog muy sencillo con muy poco código escrito.

Django es un framework pensado para hacer aplicaciones webs. Un framework no es más que un conjunto de programas, funciones, utilidades y un gran etcétera pensado para solucionar problemas típicos en el desarrollo de aplicaciones webs. Digo que está pensado para hacer aplicaciones webs porque también se pueden usar muchas de sus características para realizar otro tipo de aplicaciones, como ser de escritorio.

Existen muchos frameworks para desarrollar aplicaciones webs, pero de los que he probado o visto, este es el que más me ha gustado por su rapidéz y su simpleza a la hora de programar. Además me ha inspirado a hacer aplicaciones webs ya que nunca antes había indagado en el tema.

Este framework se utiliza para cualquier tipo de aplicaciones webs, desde algo muy sencillo hasta algo más complejo. He trabajado en proyectos extremadamente simples en dónde el usuario simplemente necesita administrar contenido y que sea visualmente fácil de localizar hasta una tienda online o un sistema de e-learning dónde se dictan cursos por internet.

La historia de Django se remonta al año 2003 en dónde la gente que desarrollaba el sitio para el diario Lawrence Journal World se estaba dando cuenta que había mucho código que estaban repitiendo, muchas funciones útiles que necesitaban en otros proyectos y que compartían con otros sitios. Además, en el desarrollo de nuevos sitios se daban cuenta que en el otro proyecto más antiguo la clase de problemas que se habían presentado eran muy similar a los que estaban teniendo actualmente y en el otro proyecto ya lo tenían resuelto. En pocas palabras, así es como nació Django: juntaron todo eso que habían desarrollado durante años, lo pulieron, generalizaron varios aspectos para que sea fácilmente modificable, charlaron,  se pusieron de acuerdo, eligieron un nombre y en 2005 lo liberaron como Software Libre.

¿Qué más se puede decir? Desde ese momento no ha parado de crecer y la comunidad que lo rodea sigue proponiendo ideas, solucionando nuevos problemas, creando nuevas funciones y utilidades, etc. Es muy activo el desarrollo de este framework y eso lo hace muy potente y extendible.

Django está construido siguiendo el patrón de diseño MVC (Modelo - Vista - Controlador) que consiste básicamente, en separar y aislar los componentes de la aplicación. Django cambia un poco el nombre de este patrón y se llama a sí mismo como MTV (Modelo - Template - Vista), entonces el mapeo con el clásico patrón sería Modelo-Modelo, Vista-Template, Controlador-Vista. Por lo tanto, si ya conocen este patrón de diseño, al principio puede ser un poco confuso.

Los diferentes componentes son:

• Modelo: los datos de la aplicación en cuestión. Es todo lo relacionado con la base de datos; la descripción de las tablas se realiza en los archivos models.py escribiendo código Python.
• Template: está asociado a la interfaz de usuario, es quien dice cómo se van a mostrar los datos al usuario, cuál va a ser su disposición en la pantalla y cuales widgets se van a utilizar para cada uno. Esto se hace mediante archivos HTML's con un poco de código de template de Django.
• Vista: es la parte encargada de procesar y ordenar los datos obtenidos del modelo o bien ingresados por el usuario.

Considerando este ejemplo: "Un usuario ingresa al home del sitio, se le muestra un formulario en dónde puede dejar sus datos para suscribirse a las noticias". La interacción entre las diferentes partes queda dada de esta manera:

• Al ingresar al home se le presenta al usuario una página que contiene el formulario en algún lugar de la misma, esta estructura está definida en el Template.
• El usuario ingresa sus datos (nombre y apellido y luego su dirección de mail).
• Estos datos son enviados a la (función) Vista que maneja esa petición. Es esta vista la encargada de "manipular" estos datos, por ejemplo poniendo el nombre y el apellido en mayúsculas y comprobando que la dirección de mail sea válida (que contenga una arroba y un punto mínimamente).
• Luego de esta verificación, la Vista le informa al Modelo que puede guardar estos datos en la base de datos ya que son correctos.

Una vez que tenemos instalado Django en nuestro sistema (la instalación está cubierta en éste documento) podemos comenzar un proyecto desde cero. Para eso debemos ejecutar el programa django-admin.py e indicarle que queremos crear un proyecto nuevo mediante el comando  startproject seguido del nombre del proyecto.

NOTA: no está permitido ponerle cualquier nombre al proyecto; por ejemplo, no se pueden usar espacios o guiones medios. El nombre del proyecto tiene que ser un nombre de módulo de Python válido.

Una vez que tenemos creado el proyecto, podemos ejecutar el servidor web de desarrollo que trae Django consigo. Para esto ingresamos al directorio que va a tener el mismo nombre del proyecto y ejecutamos el programa manage.py con el comando runserver. De esta forma le indicamos a Django que levante el servidor para este proyecto específicamente.

Debe quedar bien claro que este servidor es sólo para desarrollo y de ninguna manera debe ser utilizado para un sitio que está en producción ya que no pretende ser utilizado para eso. Lo bueno de este es que es muy útil a la hora de programar el sitio, ya que posee auto-reload. Esto es, cada vez que modificamos un archivo de nuestro proyecto el servidor se reinicia cargando la nueva configuración. Por lo tanto, al comenzar el desarrollo lo ejecutamos, luego modificamos los archivos y lo único que hacemos es presionar F5 en nuestro navegador para ver los cambios a medida que vamos avanzando o probando nuevas configuraciones.

Si ahora abrimos un navegador y apuntamos este a la dirección http://localhost:8000 vamos a ver un mensaje de bienvenida de Django indicando que el proyecto funciona correctamente.

Los archivos que nos crea el comando django-admin.py son realmente poquitos a diferencia con otros frameworks y cada uno tiene una función muy bien definida:

• __init__.py: este archivo no está relacionado con Django particularmente, sino que es más específico de Python y le indica que el directorio actual es un módulo.
• manage.py:es un programa que se utiliza para interactuar con este proyecto en particular. Es similar a django-admin.py pero específico de este proyecto. Mediante este programa se puede actualizar la base de datos, ejecutar el servidor de desarrollo, correr tests, etc.
• settings.py: en este archivo se encuentra toda la configuración del proyecto en general; la conexión a la base de datos, qué tipo de base usar, en qué lenguaje está el sitio, etc.
• urls.py: en este archivo se encuentran todas las url's disponibles para nuestro sitio.

Como dijimos en la diapositiva anterior, Django tiene un archivo llamado urls.py en dónde se encuentra la definición de todas las url's del proyecto en cuestión. Estas url's están asocian un nombre con una función vistaencargada de procesar la petición web (request). El nombre está dado mediante una expresión regular y prácticamente puede ser de la forma que más nos guste. La función vista puede ser asociada mediante una cadena de caracteres indicando el path hacia esa función o bien el objeto función de Python. También se pueden asociar varias url's hacia la misma vista, esto es muy útil cuando el proyecto estuvo en producción durante un tiempo y luego se decidió cambiar el nombre de una url para que sea más legible o algún otro motivo, entonces podemos hacer que siga funcionando la url vieja (para los usuarios viejos) y además agregar la nueva url (para los usuarios nuevos).

Puede que nosotros queramos pasar argumentos por la url, por ejemplo si tenemos un blog quizás la url sea algo similar a /año/mes/dia/slug-postpor lo tanto vemos que tenemos 4 argumentos conocidos en el nombre de la url. Para estos casos podemos usar los grupos de las expresiones regulares para que cada grupo sea pasado como un argumento posicionales a la vista que va a manejar la petición o sino podemos utilizar grupos nombrados que van a ser pasados como argumentos keyword.

De esta manera tenemos un control absoluto sobre los nombres de las url's ya que Django nos permite un procesamiento granular de los nombres gracias a que soporta las expresiones regulares en su definición. Existen otros frameworks que no nos permiten esta definición de url's sino que utilizan el nombre de la función o la estructura de los directorios para dar el nombre a la url, lo cuál no me parece que sea cómodo a la hora de modificar un nombre o hacer un poco de refactoring :S

Hemos estado hablando de Vistas casi sin hacer ninguna diferencia con una función de Python y es porque simplemente (casi) no la hay. Una función vista no es más que una función común de Python que recibe como primer argumento el request (un objeto HttpRequest de Django) y retorna un response (un objeto HttpResponse de Django). Eso es todo, en el medio la función puede realizar cualquier tipo de operación que Python lo permita :)

Un proyecto no es más que un puñado de aplicaciones de Django, pero ¿qué es exactamente una aplicación Django?. Bueno, simplemente es un conjunto de archivo de código fuente de Python agrupados en una carpeta con el nombre de la aplicación :) .

Lo bueno de esta distinción es que permite compartir una misma aplicación entre varios proyectos, ya que cada aplicación cuenta con sus modelos, sus vistas y sus propios templates. Además puede ser que también utilice modelos de otra aplicación, por lo que para su correcto funcionamiento deben compartirse ambas aplicaciones.

Por ejemplo, si en algún proyecto solucionamos un problemao agregamos una funcionalidad buena y queremos que también esté en otro proyecto, simplemente copiamos la carpeta que contiene la aplicación, la configuramos en el proyecto y listo.

Todas las aplicaciones que están dentro del mismo proyecto comparten las configuraciones de éste, por ejemplo el idioma, la conexión a la base de datos, el template base utilizado y muchas otras configuraciones más.

La forma de crear una nueva aplicación es indicarle esto al programa manage.py del proyecto. Para esto lo ejecutamos con el comando startappy le pasamos el nombre de la aplicación como argumento. Como resultado, este programa nos crea el directorio con el nombre de la aplicación que elegimos y dentro de esta tres archivos:

• __init__.py:este archivo le indica a Python que este directorio es un módulo.
• models.py: en este archivo va la definición de todos los modelos de esta aplicación.
• views.py: acá va la definición de todas las vistas de esta aplicación.

Como charlamos antes, los modelos hacen referencia a la base de datos y son propios de cada aplicación aunque pueden ser compartido por varias aplicaciones del mismo proyecto. Por ejemplo, en Django existe un modelo llamado User que es usado por la mayoría de las aplicaciones que escribimos.

Este framework soporta diferentes "backends" de bases de datos, entre ellos MySQL, PosgreSQL, SQLite3 y Oracle. También está permitido extender el framework para soportar otras bases de datos, aunque nunca lo he necesitado. En este caso vamos a utilizar SQLite3 ya que es muy sencillo de configurar y es muy útil para desarrollar por su simpleza.

En esta versión de Django está soportado utilizar múltiples bases de datos y aunque nunca lo he utilizado aprendí a configurar la base de datos pordefaultdel proyecto. Para esto hay que modificar el diccionario DATABASES que se encuentra en el archivo de configuracionessettings.py.

El procedimiento para definir modelos en nuestra aplicación es bastante sencillo. Una vez que tenemos pensadas las tablas que necesitamos en nuestra base de datos abrimos el archivo models.pyde la aplicación a la cual le queremos agregar un modelo y definimos la tabla con sintaxis Python definiendo una nueva clase que hereda de django.db.models.Model;asignando un atributo a la clase por cada columna que queremos en la tabla.

Con esto se puede notar que no es necesario saber SQL para poder definir los modelos, aunque sí recomendable. Pero lo que quiero decir es que se pueden definir los modelos de la base de datos con un mínimo conocimiento de SQL.

En esta diapositiva estamos definiendo el modelo Post que representa un post en nuestro blog. Las columnas que queremos que tenga esta tabla son título, contenido y etiquetas.De la misma forma que en SQL cada una de las columnas son de un tipo de dato en particular, los atributos de nuestra clase también. Entonces, necesitamos indicarle a Django qué tipo de dato es cada uno de sus atributos. Por ejemplo, vemos que el título es un campo de caracteres de longitud máxima de 60, el contenido es campo de texto y las etiquetas es una relación muchos-a-muchos con Etiqueta (un modelo que todavía no definimos).

Django automáticamente crea una columna llamada id en la tabla de SQL y es incrementada automáticamente cada vez que se crea una nueva fila.

Más adelante veremos que Django sabe cómo representar cada uno de estos campos cuando son utilizados en los Templates para mostrárselos al usuario en la pantalla.

Una vez que tenemos creados nuestros modelos, y si tenemos algún conocimiento de SQL, podemos preguntarle a Django cuál es el código SQL que va a ejecutar para crear los modelos que nosotros definimos mediante clases de Python. Para eso podemos utilizar el comando manage.py con el argumento sql seguido del nombre de la aplicación que queremos ver.

Agregamos estos dos nuevos modelos al archivos models.py de la aplicación posts que estamos editando recién.

Una vez que tenemos definidos los modelos en la aplicación, podemos instalar esta aplicación en el proyecto actual. Esto sirve para indicarle a Django qué aplicaciones pertenecen a este proyecto y qué modelos, vistas y templates están disponibles para este proyecto.

Para esto, editamos el archivo settings.py y agregamos nuestra aplicación a la variable INSTALLED_APPS, de esta forma 'newblog.posts'.Una vez que tenemos nuestra aplicación instalada podemos correr el comando que mencionamos antes: manage.py sql posts y veremos en la salida estándar el código SQL que Django va a ejecutar cuando le indiquemos que cree las tablas. En este momento podemos verificar que sea correcto y de no serlo modificar nuestros modelos para que lo sea.

Lo que sigue, una vez que vemos que nuestro SQL es el correcto, es decirle a Django que cree las tablas por nosotros. De la misma forma que podríamos copiar el código SQL que Django nos mostró y ejecutarlo nosotros mismos lo puede hacer Django. Entonces le decimos esto con el comando manage.py syncdb.

Este comando busca todas las aplicaciones instaladas (listadas en INSTALLED_APPS) y crea todas las tablas de esas aplicaciones. La primera vez que ejecutamos syncdb Django nos va a preguntar por un usuario Administrador y su clave, que será un usuario que usaremos más adelante para administrar algunas cuestiones del proyecto.

Como venimos hablando, un proyecto de Django está compuesto por varias aplicaciones y éstas son reutilizables. Es por esto que Django viene de fábrica con algunas aplicaciones y mini-frameworks útiles para los desarrolladores e incluso para el usuario final.

Por ejemplo viene con un framework para manejar comentarios en los modelos, otro para exportar feeds rss en diferentes formatos, otro para manejar mensajes temporales a los usuarios, y muchos otros. En este caso vamos a ver la aplicación admin que es utilizada como ABM (alta-baja-modificación) de los modelos de nuestro proyecto. Incluso existen algunos sitios que se basan en esta aplicación (modificada) como la principal del sistema.

Al comienzo dijimos que Django nos simplificaba y resolvía varios problemas, bueno, este es uno de esos casos. Normalmente mientras uno está desarrollando es necesario modificar datos o simplemente agregar datos a la base para hacer algunas pruebas de las funciones. Es acá donde entra en juego en primera instancia esta aplicación, ya que nos facilita mucho esto por su sencillo uso.

Si estamos haciendo un sistema en dónde es necesario que el usuario final cargue sus productos en este, se pueden definir todos los modelos necesarios y luego configurar esta aplicación que trae Django para que el usuario pueda empezar a cargar sus productos a la base de datos sin siquiera haber terminado el desarrollo del sistema. Lo cual ahorraría mucho tiempo.

La aplicación admin que viene con Django se instala de la misma forma que se instala cualquier otra aplicación:

• se agrega el nombre de la aplicación a la variable INSTALLED_APPS
• se agrega la url en la cuál queremos que se encuentre esa aplicación
• se sincronizan los modelos de esta aplicación ejecutando el comando syncdb

Una vez que tenemos esto hecho, podemos ir a la URL que definimos y veremos la aplicación admin funcionando. Esta aplicación es bastante grande y permite ser tunneada bastante para que cumpla los requerimientos del usuario o simplemente luzca mejor, es por esto que probablemente queramos configurar algunas cosas más luego de haberla instalado para que sea vea como queremos. Entonces, para que se vean los modelos que hemos definido en nuestras aplicaciones hay que registrarlos.

Las vistas en Django son simples funciones de Python que reciben un HttpRequest y devuelven un HttpResponse. En realidad esto es todo lo necesario a saber para definir una vista de Django correctamente. Después hay cosas que "habitualmente hacemos" para manejar el requerimiento del usuario, por ejemplo, si este ha ingresado datos hacemos una diferencia entre el método GET y POST, una vez que tenemos los datos que el usuario ingresó, los validamos y luego los guardamos en la base de datos. Por el contrario la primera vez que se le muestra el formulario al usuario será mediante un GET, entonces en este caso lo que hacemos es renderizar el formulario en el template correspondiente.

Entonces, lo más común es que cada vista tenga al menos dos caminos: uno para el GET y otro para el POST separados por un ify en cada caso se retornará lo que corresponda o se lo redirigirá al usuario a otra URL. También se puede renderizar el mismo template en ambos casos pero con diferentes valores en sus variables.

El workflow habitual para definir una vista consiste en importar los módulos que se utilizarán en esta vista, por ejemplo render_to_response, PIL,etc. Luego se define una función Python con el primer argumento con el nombre *request* y luego los demás argumentos que vienen por la URL (ya sean como grupos nombrados o no). Seguido de esto se escribe el cuerpo de la función como antes comentamos y finalmente se edita el archivo *urls.py*mapeando una url a la nueva vista que acabamos de definir.

|image11|

En este ejemplo se ve claramente lo que acabamos de explicar. Las primeras tres líneas importan las funciones, modelos y formularios necesarios para definir la vista. Luego se define la vista llamando al primer y único argumento *request*y en el cuerpo de la vista se maneja el método GET y el POST.

Para el método GET lo que se hace es crear un formulario para el modelo Post y luego se lo renderiza en el template agregar_post.html de la aplicación Post.

Cuando la petición web es un POST se crea un un nuevo formulario a partir de los datos enviados por el usuario (mediante el POST), luego se pregunta si es válido. Si lo es, se guarda en la base de datos este formulario, creando un nuevo objeto del modelo Post y con esto una nueva fila en la tabla Post del SQL. Una vez que se hace esto se redirige al usuario al home (root) de nuestro sitio web (/) mediante el código de respuesta 302.

|image12|

En el ejemplo anterior hablamos de renderizar un template, pero hasta ahora no vimos como lucen estos y tampoco cómo escribirlos. Los templates no son mucho más que código HTML y un poco de código Django Template. Si tenemos un poco de conocimiento sobre HTML y un poco de conocimiento estructuras de flujos nos va a resultar muy sencillo escribir los templates que Django luego va a renderizar.

Existen tres grandes conceptos en el código Django Template, los filtros, las variables y las etiquetas. Las variables son justamente eso: variables, las cuales contienen un valor que puede ser insertado en cualquier lugar del template encerrando su nombre entre dos llaves ({{ variable }}). De esta forma, en el lugar que ingresemos esa sustitución se pondrá el contenido de la variable en ese lugar.

Las etiquetas se utilizan para organizar el flujo del programa y así mostrar los datos correspondientes en cada caso. Algunas etiquetas comúnmente usadas son if, for, trans, blocktrans, comment, etc. Estas se encierran entre llaves simples y un signo de porcentaje ({% comment %}).

Otra gran característica de los templates es la herencia. Normalmente se utiliza para no repetir código y que sea más fácil de mantener. Los sitios habitualmente tienen un header y footer estático, que no cambian al navegar el sitio: este puede ser un menú en el header y algún texto que diga "Copyright Humitos ©" o similar en el footer. Entonces, para estos casos en los cuales yo quiero tener dos porciones de mi página que sé que no van a cambiar en todo el sitio puedo escribir esto en un template base e indicar cuáles son las partes de este template que se pueden cambiar. Luego en otro template, el que hereda de base, defino cuales son los bloques del template que estoy heredando que deseo cambiar y así sólo modifico el contenido relevante y la porción del sitio que se repite en todos los templates me queda centralizado en un sólo archivo.

En la variable TEMPLATE_DIRS del archivo settings.py están listados los directorios en los cuales Django debe buscar los templates que las vistas van a usar para renderizar su contenido. Por lo tanto, debemos agregar los directorios dónde vamos a tener nuestros templates a esta variable.

Además, existe una notación específica para ubicar los templates dentro de cada aplicación y que sean encontrados automáticamentepor Django sin tener que agregar cada uno de los directorios de nuestras aplicaciones. Esta notación es <app_name>/templates/<app_name>/template.html.Por ejemplo para el template agregar_post.html que usamos anteriormente en la vista la ruta parados desde el root del proyecto sería: posts/templates/posts/agregar_post.html

Los filtros se aplican a las variables y se utilizan para modificar el valor que esta contiene o bien darle formato. Por ejemplo si en la variable tenemos una fecha y la queremos mostrar comodd/mm/aaaa se puede usar el filtro date.La forma de utilización es similar a la de la sustitución de la variable pero seguido del nombre va un pipe y luego el nombre del filtro. Por ejemplo, para pasar el contenido a minúsculas se puede usar el filtro lower: {{ variable|lower }}.

Otra de las cosas que me gusta de Django es lo simple y fácil que es extenderlo. Me ha pasado varias veces que necesito hacer un filtro o un templatetag y me he sorprendido lo fácil que es escribir uno propio. También con esto hay que tener cuidado ya que lo que se puede hacer en un filtro o un templatetag es bastante poderoso, pero en realidad, éstos no están pensados para tener mucha lógica, sino más bien están pensado para hacer alguna mínima modificación en la estructura o en el valor de la variable. La lógica compleja sobre qué datos o cómo se deben mostrar debería estar en la vista y no en el template.

¿Preguntas? Usen los comentarios para hacerlas, las contestaré a medida que pueda :)

Algunos links de referencia:

• http://www.djangoproject.com/
• http://docs.djangoproject.com/en/1.2/
• http://django.es/
• http://django.es/docs/intro/general/
• http://django.es/docs/intro/tutorial01/
• http://trac.usla.org.ar/django-book