La parte fundamental de Django: El patron MTV

En el articulo anterior Adán ya nos había comentado sobre lo indispensable que es el “ceñirse fielmente” al patrón MTV (o MVC) al utilizar Django. Ahora hablemos de los templates, parte importante de este patrón.

Templates

Nos dice Adán que una de las partes más fuertes de Django es su motor de plantillas, el mismo permite abstraer completamente la presentación de las demás partes de la aplicación, esto gracias a etiquetas y filtros:

Filtros
“En las plantillas de Django hacemos uso de la rica cantidad de filtros que pone a nuestra disposición. Desde convertir a mayúsculas, eliminar etiquetas html y agregar saltos de línea.” comentó Adán y agregó que gracias a estos filtros es más fácil tener una clara separación entre datos, lógica y presentación.

Para dar formato a una fecha:

Ejemplo de filtros en plantillas

<p class=”fecha”>{{ video.fecha|date:"F • j"}}</p>

Algunas baterías incluidas o Módulos Django

Ya habíamos mencionado que Django es el framework con baterías incluidas, aqui te comentamos algunas de ellas:

Localización
Nos comenta Adán sobre GeoIP, una librería de localización basada en C: “La integración que trae Django con esta librería da mucho poder a la hora de crear sitios internacionales.” Agrega que “esta librería básicamente es una base de datos gigantesca, optimizada para ser de rápido acceso, con los rangos de direcciones IP por regiones, países, etc.”

Feed
A su vez el módulo de sindicalización se ciñe perfectamente a los patrones propuestos por Django, permite tener todos los métodos y propiedades de los modelos, así como usar plantillas y filtros para la presentación.

Formularios
Django viene con una forma fácil de crear formularios a partir de modelos, con validación automática y completamente personalizable desde la plantilla, Adán nos explica como:

Clase para formulario automático

Un formulario es tan sencillo como:

class VideoComentarioForm(ModelForm):
class Meta:
model  = VideoComentario
fields = ('autor', 'autor_email', 'autor_url', 'content')

Plantilla para personalizar formulario

<form>
<label for="author">nombre</label>{{ form.autor }}
{{ form.autor.errors }}
<label for="email">email</label>{{ form.autor_email }}
{{ form.content.errors }}
…
</form>
[ formulario ]

y personalizar la plantilla es tan sencillo como:

[ plantilla formulario ]

Lo poco que no tiene Django, se soluciona

Si es que Django no incluye algunos módulos, es extremadamente sencillo crear módulos adicionales que encapsulen funcionalidad extra.

Imágenes

En Mejorando.la hay diferentes tipos de imágenes; estas imágenes distintas son generadas recortando y optimizando desde el administrador, cuando se crea el video. Nos cuenta Adán que esta tarea fue muy fácil de realizar gracias a la librería PIL.

“Esta librería está en C por lo que es muy veloz, en Python te vas a encontrar muchos módulos en C, sobre todo aquellos que requieren más procesamiento.” agrega Adán.

Ejemplo de uso del módulo PIL

import Image
image = Image.open(path)
image = image.resize((newWidth, newHeight), Image.ANTIALIAS)
image.save(path)[ ejemplo ]

Consejos para mejorar la web con django y python

Adán nos dio algunas consideraciones para tener en cuenta al llevar el sitio a producción:

• Configurar un administrador, que recibirá alertas cuando algo salga mal.
• No olvides crear tus páginas 400 y 500 (páginas de errores).
• Profundizar en los múltiples parámetros de configuración que ofrece Django. Antes de llevar cualquier sitio Django a producción lee la guia para que veas todo lo que puede “tweakear”.
• Con una línea puedes activar el uso de memcached para cachear las páginas de Django. Es muy simple y puede hacer una gran diferencia en el rendimiento de tu aplicación cuando tienes muchas visitas.
• Hay muchas formas de llevar a producción un sitio Django. Mejorando.la utiliza una combinación de Nginx (para archivos estáticos) y mod_wsgi, que es un módulo de apache, para el código python.
• Con respecto al hosting, hostgator es una buena opción para iniciar probando Django, sin pagar mucho.

El trabajo en equipo. No todo es programación

Además de las tecnologías que mencionamos, también se necesitaron herramientas que ayudaron al trabajo en equipo.

1. BaseCamp, lo más importante es mantenerse comunicado con tu equipo.
2. Github, es una parte central para asegurar la fluidez del trabajo ya que acelera mucho el proceso de comunicación al llevar un registro de “quién hizo qué”. En Mejorando.la se manejan dos ramas principales, hay dos sitios montados uno en desarrollo y otro que es el produccion.
3. Feedback, al desarrollar un sitio es importante lo que opinan los usuarios, para ello Twitter ha brindado una enorme cantidad de feedback muy valioso, “nunca ignoren a un usuario que les reporta un bug”.
4. Diferentes dispositivos, cada uno de los que forman parte del equipo cuentan con dispositivos diferentes, aún así ayuda cualdo alguien manda un error con una captura de pantalla en X dispositivo.
5. Newrelic, es una herramienta muy completa para el monitoreo del sitio.

Es importante que estés consciente de que con Django las posibilidades son muchas, y conforme vayas profundizando en el tema irás aprendiendo trucos.

Ya sabes cómo se utiliza python, django y otras tecnologías para desarrollar el sitio de Mejorando.la. El sitio es Open Source y el código está disponible en Github.

Y si quieres profundizar más en el tema recuerda que puedes revisar la guía Django y la guía Python.

Síguenos en: @maestros | Fan page

Nuevos capítulos de la guía Python

En busca de generar mayor contenido los capítulos de Python aún no se han convertido en eBook como usualmente lo hacemos, Alvaro Martínez, trabaja desde hace tres años con Python, es desarrollador y moderador del foro Python en Foros del Web ha realizado 4 capítulos para integrar en la guía desarrollando los temas:

• Cadenas de Texto.
• Secuencias (Tuplas, listas y cadenas).
• Expresiones regulares en Python.
• Trabajando con listas, funciones y archivos.

Algunos temas que Alvaro desarrollará han sido tratados en otros capítulos por Eugenia Bahit, sin embargo, el fin es también aclarar algunos aspectos de forma específica. No olvides revisar los capítulos anteriores de la guía Python:

• Programación Orientada a objetos en Python
• Métodos y Propiedades en Python
• Listas, tuplas, diccionarios y estructuras de control
• Trabajando con templates, archivos y condicionales
• Excepciones, helpers y refactoring
• Herencia, relación entre dos o más clases
• Testeando código con doctest en los comentarios
• Interfaces gráficas con wxPython
• Finalizando con Python y MySQL

El lanzamiento del primer capítulo es el miércoles 6 de junio y a partir de ese día se publicarán semanalmente lo cuatro capítulos. ¿Qué te parecen los temas? ¿Le seguiste la pista a las publicaciones de Eugenia?

Síguenos en: @maestros | Fan page

El motor de plantillas

Django posee un componente conocido como “el motor de plantillas”, este motor brinda un poderoso mini-lenguaje para definir detalles de la capa de la aplicación, que visualizará el usuario. Esto refuerza la separación de la lógica de programación y la lógica de presentación.

Las plantillas pueden ser desarrolladas y mantenidas por cualquier persona con un poco de conocimiento de HTML y lógica común. No necesita fundamentos de Python. Puedes revisar la documentación con respecto al lenguaje de plantillas.

Algunos ejemplos fueron mostrados en el capítulo anterior

Etiquetas y Filtros

Es necesario para aplicar las plantillas con Django, conocer más sobre su propio mini-lenguaje de plantillas. Para ello tenemos las siguientes chuletas (cheatsheets):

Django: Etiquetas y Filtros

Django: Formatos de fecha

Y como siempre les hago recordar, la revisión a la documentación oficial es muy importante. Están divididas en etiquetas y filtros predefinidos y el lenguaje de plantillas de Django para programadores de Python.

Las plantillas de nuestro proyecto

En el capítulo anterior, trabajamos con algunas plantillas simples, sin entrar en detalle de su funcionamiento, esta semana modificaremos las plantillas, utilizaremos algunos filtros y etiquetas predeterminadas, obviamente veremos a detalle de que tratan.

base.html

Esta es una nueva plantilla, no habíamos utilizado anteriormente alguna de este tipo, esta plantilla base, hace exactamente lo que su nombre sugiere, sirve de base para las demás.

base.html

En esta plantilla es importante notar, que se encuentra la estructura principal de toda la aplicación. Ademas se usa la etiqueta {% block _______ %} {% endblock %} (reemplaza _______ con el nombre del bloque), esta etiqueta se reemplazará con contenido en cada una de las plantillas que restan. Por ahora agregaremos CSS dentro de la etiquetación HTML, no lo hacemos todavia desde un archivo CSS porque esto lo veremos con mayor detalle en el capítulo de archivos estáticos.

inicio.html

Esta es la plantilla que estamos usando para la página de inicio, y debe quedar con las siguientes modificaciones:

inicio.html

• {% extends ‘base.html’ %}, esta línea permite importar la plantilla base.html y reemplazar cada vez que encuentre los bloques, con los de esta plantilla.
• {% comment %}{% endcomment %} es un ejemplo de como pueden incluirse comentarios en el lenguaje de plantillas de Django, todo lo que se encuentre dentro de estas etiquetas, será ignorado.
• {% with %} permite poner la cantidad de elementos de alguna respuesta y puede ser usado para mostrar palabras en plurales, dependiendo de la circunstancia.
• {% for dato in recetas %} permite acceder a cada receta en particular.
• {% cycle ‘impar’ ‘par’ %} permite iterar con los valores ‘impar’ o ‘par’, que pueden verse afectados con algunas reglas en CSS simples que se encuentran en {% block style_css %}
• {% empty %} es usado en caso de que no existan elementos en las recetas.

usuarios.html

La plantilla que muestra los usuarios registrados:

usuarios.html

Además de las etiquetas vistas anteriormente, aquí podemos encontrar:

• {{dato.username|capfirst}} esto se usa para capitalizar el nombre del usuario (primera letra en mayúscula)
• Bloque {% if %}{% endif %} para comprobar que receta pertenece al usuario actual del bucle {% for %}

recetas.html

Esta plantilla nos muestra la lista de recetas registradas:

recetas.html

• {% url principal.views.detalle_receta dato.id %} esta etiqueta, trabaja con views.py (ubica una vista y le pasa un parametro), se traduce en /receta/dato.id, donde dato.id es reemplazado por la id de la receta del elemento actual del bucle {% for %}

receta.html

Esta plantilla se usará para mostrar los detalles de cada receta registrada:

receta.html

Ademas de todas las etiquetas usadas y ya explicadas anteriormente se puede notar:

• {{receta.titulo|title}} transforma los títulos de la receta en formato título (la primera letra de cada palabra en mayúscula.
• {{ receta.tiempo_registro|date:’SHORT_DATETIME_FORMAT’ }} configura la impresión de fecha como: dd/mm/aaaa hh:mm (ejemplo: 20/05/2012 21:05), se puede ver mas formatos de fecha a usar en los cheatsheets de arriba.

Practica y practica

La mejor forma de aprender Django es practicando, así que supongo que lo estas haciendo, durante todos los capítulos, ahora toca que crees tus propias plantillas, para tus propias consultas y vistas, que seguramente ya programaste con ayuda del curso de Django.

No te olvides de revisar la documentación por si buscas más ejemplos y detalles de las diversas etiquetas, es la mejor fuente para aprender más sobre este estupendo framework.

Puedes leer también: Cómo se utiliza Python y Django en Mejorando.la y si el ingles no es problema para tí, puedes ver una charla del PyCon 2012 sobre las plantillas en Django:

Eso es todo por esta semana, deja tus comentarios como siempre, que ayudan a mejorar el contenido del curso, y que ayudan de manera importante a todos los que siguen el curso, que tengan un buen inicio de semana con Django .

Sergio Infante Montero para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

En Latinoamérica existe un problema con el tema del dinero, quizás sea una cuestión cultural, quizás nuestra educación o simples paradigmas que nos asechan. Pero, nos cuesta hablar de dinero, negociar, hablar de presupuestos y lo más común nunca sabemos cuánto ganamos realmente, decimos -más o menos-, -aproximadamente- ¿acaso no sabemos el costo de nuestro trabajo? ¿no sabemos negociar? ¿por qué nos andamos por las ramas? ¿sabes cuánto quieres ganar? ¿por qué nos sentimos ofendidos al hablar de dinero?

¿Cuánto vale una hora de tu tiempo?

En las iniciativas que tenemos en nuestros proyectos como Maestros del Web, Foros del Web, 120segundos, Mejorando.la con sus cursos y conferencias siempre tenemos un equipo de personas apoyando como socios y de la comunidad que se ofrecen apoyarnos, como agradecimiento al conocimiento que les hemos aportado a través de nuestros proyectos. Nos alegra la gente entusiasta, pero también nos motiva la gente que quiere hacer negocios, ofrece soluciones a nuestras necesidades y no temen ponerle un precio.

Si eres freelancer, emprendedor y quieres tener tu propia empresa, debes romper con la dinámica de no tener respuesta cuando alguien te pregunta ¿cuánto ganas al mes? ¿qué cuesta una hora de tu trabajo? ¿cuánto cobras por asesorar? ¿cuánto te pagaron por tu último proyecto? ¿cuánto me cobras por hacerme ABCD tareas? ¿cuánto me costaría o me puedes dar un estimado? ¿en tu sitio están los costos? si no sabes qué contestar, toma un tiempo para hacer los cálculos y define tus costos ¿por qué te da vergüenza o pena decir el valor de tu trabajo?

Aprendamos a negociar en todas la áreas

Existe una dinámica que debemos practicar todos los días, con todas las personas, relaciones y objetivos de vida: negociar. El negociar no es sólo cuestión de dinero, también de intereses, bien común, calidad de vida y justicia. Pero, la negociación no es una cualidad o valor que nos instruyen desde pequeños, porque nos enseñan a obedecer y acatar las reglas de los que sí saben. Eso se traslada al valor que tenemos de nuestro trabajo, los negocios y entonces preferimos que sea una empresa la que ponga el precio.

Que tu trabajo, una hora de tu tiempo y tu asesoría tenga un precio, está ligado con la autoestima que tengas en(de) tu trabajo. Puede que a muchas personas les moleste que no quieras tomarte un café con ellos para contarte de sus proyectos y tener tu opinión. Es posible que al decirles ¿quieres una asesoría? les parezca una ofensa, pero sí tu no te tomas en serio entonces ¿por qué otras personas lo harán? el rol que quieras tomar también es una negociación contigo mismo.

Siempre debes obtener un beneficio a cambio

Cuando se trata de trabajo, siempre debemos obtener un beneficio a cambio, ya sea económico, experiencia, reconocimiento, etc. Cuando somos jóvenes es común que “regalemos nuestro trabajo” como se suele decir, pero en realidad estamos ganando experiencia, práctica y aprendiendo del medio. Sin embargo, debemos saber cuándo es bueno invertir nuestro tiempo en actividades, iniciativas, comunidades o proyectos porque no siempre obtenemos resultados que suman.

Hay quienes al apoyar afirman con orgullo que -no lo hacen por dinero- yo creo que no existe nada malo en ganar dinero por nuestro esfuerzo, apoyo y dedicación. Lo único que debemos aprender muy bien es a saber negociar. Cuando alguien sabe negociar, obtiene siempre ganancias de su esfuerzo, quitemos de nuestra mente que es malo hacer las cosas por interés o dinero. Diseñemos modelos y dinámicas que nos permitan ganar y así mismo construir con otras personas para que todos salgan ganando de igual forma.

Espero que sigamos la reflexión en los comentarios, estoy segura que ustedes tendrán mucha experiencia que compartir con relación al tema, sigamos aprendiendo a negociar y ser mejores freelancer en este medio tan competitivo. Feliz fin de semana. Enjoy!

Imagen: 401kcalculator

Stephanie Falla Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Leonidas Esteban, Renzo Avalos y Adan Sanchez son quienes hace unos meses estuvieron trabajando para lograr el sitio que hoy se puede disfrutar al ingresar a Mejorando.la. Para lograrlo hubo todo un proceso de rediseño y reprogramación que fue posible gracias a varias herramientas y servicios que con la ayuda de Adan Sanchez te contaré a continuación.

Python y Django: Lenguaje y framework de la magia

“Al momento de planear el rediseño y reprogramacion de un sitio es importante identificar bien sus elementos y componentes principales para crear los modelos necesarios y una buena estructura” es lo primero que resaltó Adán Sanchez. Y hablando especificamente de Mejorando.la hay que destacar que el componente principal son los videos. Desde ahí parten todas las funciones que se van agregando al sitio.

Python es el lenguaje y Django es el framework detrás del sitio de Mejorando.la. Nos cuenta Adán que gracias a la flexibilidad que ofrece, se pudo realizar la reprogramación y rediseño del sitio en pocos días: “Digamos que Django se ha vuelto prácticamente un estándar como framework para desarrollo ágil.”

Es especialmente recomendado para un proyecto grande desarrollado por un equipo pequeño o cuando se trata de un sitio para entregar en pocos días.

Al consultar por qué la elección de Django y no otro, nos explicó que “Django era la solución principal, puesto que si bien wordpress es muy flexible, en Django hay aun mas flexibilidad.”

Un framework con baterías incluídas

Django trae lo que en Python se conoce como “baterías incluidas”. Desde clases para tareas sencillas como paginación, geolocalización, autentificación y caché hasta componentes bastante completos como el módulo de comentarios, notificaciones, administrador, internacionalización y feeds.

Adán explica que un sitio en Django es más limpio puesto que python tiene una estructura modular, agrega que “en otros lenguajes hay que descargarse muchos archivos y el tener tantos archivos en el directorio puede hacer mas dificil manejar el sitio”. Para “graficar” la facilidad con la que se activan estos módulos desde el archivo de configuración, nos mostró el código correspondiente:

INSTALLED_APPS = (
'django.contrib.auth', # funciones de autentificacion
'django.contrib.comments', # funciones para agregar comentarios a los modelos
'django.contrib.admin', # administrador autogenerado
)

Además afirma que es muy fácil encontrar un módulo en los repositorios para aquellas funcionalidades que no vienen incluidas en Django, un ejemplo de ello es el modulo Gravatar que se utiliza en Mejorando.la para los avatares de los comentarios.

Modelo-Vista-Controlador

“Un punto más a favor de Django es el patrón Modelo-Vista-Controlador que maneja, esto quiere decir que separas tu aplicación en tres componentes”, explicó Adán. El modelo principal en este caso seria Video, en donde un “video” tiene titulo, imagen, descripcion, comentarios.

Para entender mejor puedes ver el tercer capitulo de la guia Django y luego ver estos ejemplos:

Modelo: son los datos, en el sitio se tiene un modelo para los Videos.

Ejemplo de modelo

class Video(models.Model):
titulo = models.CharField()
slug = models.CharField()
imagen = models.ImageField()
fecha = models.DateField()
descripcion = models.TextField()

Vista: sería la presentación de este modelo, en Django entra en los templates, que reciben los datos del controlador. Hay una plantilla para cada vista: home.html, videos.html, video.html, heredando de base.html gracias al poderoso sistema de plantillas de Django.

Controlador: se encarga de elegir los datos que se van a mostrar y hacer el procesamiento que haga falta en estos, validacion y condicionamientos. En Mejorando.la hay un controlador para cada página: home, archivo de videos y página de video.

Ejemplo de controlador

def video(solicitud_http, video_slug):
video = get_object_or_404(Video, slug=video_slug)
return render_to_response('website/video.html', { 'video': video })

Unidad, código limpio y filtros.

La unidad que existe en toda la plataforma es una de las caracteristicas que más le gustó a Adán: “cualquier método que defina en un modelo estará presente tanto en el controlador como en las plantillas.”

“Los modelos de Django permiten abstraer lo que tradicionalmente se haría con SQL en clases y funciones. Esto permite tener un código más limpio.”

Por ejemplo:

SQL
SELECT titulo, descripcion, imagen FROM videos ORDER BY fecha LIMIT 10

Django

Video.objects.all().order_by(‘-fecha’)[:10]

Nos comentó también que en las plantillas de Django se hace uso de la rica cantidad de filtros que pone a disposición, desde convertir a mayúsculas, eliminar etiquetas html y agregar saltos de línea.

Gracias a estos filtros es más fácil tener una clara separación entre datos, lógica y presentación.

Sólo un comienzo

Cómo te imaginarás el proceso de rediseño y reprogramación de un sitio como Mejorando.la no se puede comentar y explicar en detalle en tan sólo un artículo, sin embargo en una proxima publicación con Adán te contaremos más funcionalidades y caracteristicas que hacen de python un lenguaje fácil de aprender y de Django el framework ideal para perfeccionistas.

Síguenos en: @maestros | Fan page

Constantemente me preguntan que lenguaje de programación aprender: Por cierto, aprende Javascript y eso no lo digo solo yo, lo dicen las estadísticas de Github donde destaca como el lenguaje más usado. Pero aquí hay un problema, ve a buscar buenos tutoriales de javascript a algún buscador y lo que encontrarás es un tsunami de desinformación.

Marketing para futuros desarrolladores

CodeCademy (no confundir con Code Academy que enseña Ruby on Rails en 3 meses físicamente en Chicago) es una incréible propuesta que ha sobresalido en su buen marketing hacia ese nicho necesitado de programadores, de rutas fáciles a un prototipo, porque ahora resulta que todos queremos aprender a programar. Incluso el alcalde de Nueva York.

Me encantaría hablar de Codecademy hablando de profesores que tenían un sueño y una vocación y la transformaron en empresa luego de mucha investigación y años de desarrollo. En el caso de Codecademy, nació en YCombinator con emprendedores que a última hora vieron que no es fácil contratar desarrolladores en Silicon Valley y buscaron la forma de entrenarlos y reclutarlos. Además tenían un mercado cautivo. Y ojo, admiro mucho a la empresa, pero me he prometido ser muy crítico en esta reseña de proyectos para no escribir lo mismo que se puede leer de ellos.

¿Podemos aprender Javascript en CodeCademy?

Si, es su primer curso. Y la plataforma es una idea muy bien armada de como combinar la gamificación (se que algunos que leen odiarán los anglicismos totalmente no aprobados por la RAE que a veces uso), una consola interactiva de programar y ejercicios prácticos para empezar desde cero.

También importante destacar que en este mercado hay otro proyecto muy interesante llamado Treehouse del que espero hacer un review más adelante en esta serie.

Lo más admirable de Codecademy es su propuesta para democratizar la teoría de programar. Todos deberían intentarlo. Y creo que su plataforma puede ser el mejor examen vocacional que cualquier futuro ingeniero o programador debería de tomar. Me convencieron cuando leí de esta college prepster (algo así como chica fresa) programando. Y no solo eso, también están en grandes ligas trabajando con la misma Casa Blanca y el gobierno de Obama.

Aún no veo si van a conseguir a los mejores programadores del futuro o si esta misma plataforma ayudará a aprender conceptos extremadamente complejos de algunos lenguajes de programación. En ese caso, yo confiaría mucho más en Hacker School y su modelo para encontrar y preparar al mejor talento desarrollador.

El 2012 y CodeYear

La primera semana de enero este proyecto lanzó una de mis campañas favoritas en el mundo de startups. CodeYear es su propuesta de aprender a programar en un año y se basan en una combinación del curso de Javascript con otro de fundamentos de la Web. Todas las semanas te envían un correo electrónico con una tarea nueva a completar en su plataforma gratuita.

Yo me suscribí, recibo los mails cada semana y jamás seguí ninguna clase luego de mis pruebas iniciales con su plataforma. Pero esto no tiene ninguna relación con mis pocas habilidades para javascript, he de aclarar.

Algo que si he aprendido con CodeYear es a diseñar una excelente landing page, trabajo de Sacha Greif que documentó con detalle.

Los detractores de CodeCademy

Algo que mencioné en el artículo sobre Khan Academy y que valida la importancia de estos modelos son las constantes críticas que tienen.

Importante también seguir los debates que CodeCademy empresa ha generado. Audrey Watters menciona que se ganó los badges y avanzó niveles, pero no ha aprendido realmente mucho. También cuestiona cuántos de los 500mil usuarios del sistema habían aprendido Javascript. Esto a finales del 2011.

Unos días atrás, Jeff Atwood criticó su campaña de que todos tenemos que aprender a programar y nos pedía que no aprendieramos a programar. Recomendada también la respuesta de Sacha Greif que nos insiste a programar a todos. Ella hizo la landing de CodeYear como comenté arriba.

Yo me quedo con la opinión de que todos debemos tener más cualidades tecnológicas porque vas a poder desarrollar prototipos de tus ideas aunque sea con entender mejor cómo usar un programa para armar presentaciones. Y Codecademy, con una reciente inversión de 2.5 millones de dólares se gana el honor de haber difundido este mensaje en menos de un año a muchísima gente. Seguiré pendiente de a donde se destinarán esos fondos.

Finalizo agradeciendo sus mensajes y comentarios sobre esta serie para re-definir la educación virtual. Khan Academy, Codecademy y mañana tocará Treehouse, aunque ya la lista de proyectos a revisar se está acumulando y eso me encanta. Hasta mañana.

Síguenos en: @maestros | Fan page

El crecimiento de su comunidad va en aumento al igual que la presencia de aplicaciones y desarrollo web. En una entrevista Julián Amaya, co-fundador de Monoku, nos confiesa estar enamorado de Python desde hace 3 años y nos comenta algunas razones del porqué está enfocado en éste lenguaje:

Una de las cosas chévere de Python es que se usa en muchas cosas, como lenguaje es muy flexible para trabajar aplicaciones nativas y juegos.

Julián menciona también que algo que le gusta de Python es que permite escribir frameworks como Django “que son muy bonitos y permiten trabajar muy fácil”. Opina que el que algunas aplicaciones trabajen Python en el Frontend en vez de Javascript y otros lenguajes que trabajan cosas que se parecen a Python muestra que “Python está aquí para quedarse y para hacer muchas cosas”.

Desarrollemos propuestas

Alvaro Martínez desarrolla en Python y es moderador del foro en Foros del Web desde el 2005, nos comenta que en principio se interesó mucho por HTML porque “lo veía como algo con lo que se podían lograr cosas interesantes”. También visitaba los foros de php y css, sin embargo, desde hace tres años participa activamente en el foro de Python.

Alvaro comenta que es importante que la comunidad que programe en Python evolucione, que hayan nuevas propuestas para asegurar su avance y desarrollo sino, por ejemplo, visitar un foro se vuelve aburrido cuando no hay más que las mismas preguntas por parte de los usuarios.

He mencionado algunas características positivas que nos hacen considerar aprender Python a quienes no saben y reafirmar porqué lo hemos elegido para desarrollar, a pesar de ellos el lenguaje tiene aspectos negativos en los cuales ambos desarrolladores están de acuerdo: Python tiene una comunidad grande pero carece de soporte, como menciona Julián no es tan fácil encontrar un servidor para Python como lo es para PHP.

¿Cómo puedo aprender Python?

Python es bastante intuitivo, ambos desarrolladores comentan que aprendieron practicando, realizando proyectos con aspectos básicos y poco a poco mejorarlos. Si quieres aprender Python y no conoces ningun lenguaje de programación Julian recomienda el libro Learn Python: The hard way que te lleva de lo básico a lo avanzado. Si tienes ya experiencia en algún lenguaje que no sea Python, “crea un proyecto” es fácil y aprendes mientras lo desarrollas.

Guía Python

En Maestros del web publicamos hace algunos meses el primer capítulo de la guía Python y aún estamos en proceso de agregar más capítulos de este lenguaje. En próximas entregas publicaremos más capítulos con autoría de Alvaro Martínez.

Síguenos en: @maestros | Fan page

En este capítulo nos dispondremos a crear un ejemplo básico de seguridad que nos permita hacer el “login” de los usuarios y a su vez bloquear el acceso a determinados usuarios según su rol, para ello tendremos que adentrarnos en como funciona la librería de seguridad de Symfony2, luego crearemos las estructuras necesarias para definir un mini-backend donde crearemos unos CRUD’s para usuarios y roles utilizando Doctrine como proveedor de usuarios.

Autenticación vs. Autorización

Representan los 2 conceptos más fundamentales de seguridad en Symfony, el primero se encarga de verificar si el usuario en cuestión está Autenticado (logeado) y se le conoce como “Firewall”, el segundo verifica si el usuario tiene los permisos o “roles” necesarios y se le conoce como “access_control”.

El primer paso es verificar si el usuario está o no autenticado, en tal caso lo deja pasar y el segundo paso es verificar si el usuario tiene el rol necesario para dicha acción, para comprenderlo mejor veamos un ejemplo básico del archivo de configuración:

# proyecto/app/config/security.yml
security:
    firewalls:
        secured_area:
            pattern:    ^/
            anonymous: ~
            http_basic:
                realm: "Secured Demo Area"

    access_control:
        - { path: ^/admin, roles: ROLE_ADMIN }

    providers:
        in_memory:
            users:
                usuario:  { password: user, roles: 'ROLE_USER' }
                admin: { password: kitten, roles: 'ROLE_ADMIN' }

    encoders:
        Symfony\Component\Security\Core\User\User: plaintext

Vemos como primer elemento definido los conjuntos de firewall y en él una “secured_area” donde:

1. pattern: es una expresión regular para hacer empatar la URL, toda ruta que empate con ello obligará al mecanismo de firewall que verifique si el usuario está autenticado, si no lo está procederá a re-dirigirlo al formulario de autenticación (en el caso anteterior mostrar el díalogo nativo de autenticación HTTP del navegador).
2. anonymous: ~: indica que permite usuarios anónimos, no se debe aplicar en caso de backends.
3. http_basic: indica que utilice la autenticación HTTP.

Por su parte el Mecanismo de Autorización “access_control” actúa de forma diferente, porque aunque dependa de que el usuario esté autenticado verifica si el mismo dispone de los permisos (roles) necesarios para determinada operación:

• - { path: ^/admin, roles: ROLE_ADMIN }indica una regla básica para autorización, donde en toda ruta que coincida al principio con /admin, el usuario debe de tener dicho rol “ROLE_ADMIN” indicado.

“providers” simplemente define el proveedor de usuario, que en este caso es en memoria, y “encoders” define el codificador de la contraseña, el cual debe ser de algún tipo de HASH como SHA512, en el ejemplo se usa texto plano. (más adelante se exponen ejemplos detallados).

Configuraciones del Control de Acceso

El control de acceso no sólo se limita a controlar que el usuario cumpla con un rol determinado para un patrón de ruta determinada, permite cierta flexibilidad con el que podrás adaptarte a las necesidades de seguridad de tu aplicación.

Protegiendo por IP
Tan simple como añadir el parámetro ip, con la misma puedes obligar a que una ruta solo se pueda acceder desde dicha ip (ideal para el backend interno):

# app/config/security.yml
security:
    # ...
    access_control:
        - { path: ^/_internal, roles: IS_AUTHENTICATED_ANONYMOUSLY, ip: 127.0.0.1 }

Protegiendo por Canal
Si dispones de un certificado SSL puedes obligar a que la ruta solo esté disponible desde https, especificando requires_channel:

# app/config/security.yml
security:
    # ...
    access_control:
        - { path: ^/cart/checkout, roles: IS_AUTHENTICATED_ANONYMOUSLY, requires_channel: https}

Protegiendo un Controlador
En ocasiones necesitamos que el controlador se encargue del control de acceso, de forma que podamos flexibilizarlo según nuestro modelo de negocios, para ello podremos acceder al contexto de seguridad desde nuestros controladores:

//dentro de un controlador
use Symfony\Component\Security\Core\Exception\AccessDeniedException;
// ...
public function helloAction($name)
{
     if (false === $this->get(’security.context’)->isGranted(’ROLE_ADMIN’)) {
          throw new AccessDeniedException();
     }
     // ...
}

También puede optar por instalar y utilizar el Bundle opcional JMSSecurityExtraBundle, el cual puede asegurar su controlador usando anotaciones:

//dentro de un controlador
use JMS\SecurityExtraBundle\Annotation\Secure;
/**
  * @Secure(roles="ROLE_ADMIN")
  */
public function helloAction($name)
{
     // ...
}

Para más información, consulte la documentación de JMSSecurityExtraBundle. Si estás usando la distribución estándar de Symfony, este paquete está disponible de forma predeterminada. Si no es así, lo puedes descargar e instalar.

Controlando el acceso desde plantilla
Incluso puedes verificar si el usuario tiene acceso desde la misma plantilla, útil para ocultar segmentos a roles específicos:
Desde Twig

{% if is_granted(’ROLE_ADMIN’) %}
     <a href="...">Delete</a>
{% endif %}

Desde PHP

<?php if ($view[’security’]->isGranted(’ROLE_ADMIN’)): ?>
    <a href="...">Delete</a>
<?php endif; ?>

Recuperando del objeto usuario
Desde un controlador, puedes acceder fácilmente a la instancia del usuario actual utilizando el Mecanismo de inyección de dependencias:

//dentro de un controlador
public function indexAction()
{
  $user = $this->get(’security.context’)->getToken()->getUser();
}

Tutorial: mini-backend de usuarios con Doctrine

Realmente el ejemplo anterior es demasiado básico como para llevarlo a una aplicación real, y una de las opciones más tentadoras es utilizar Doctrine como proveedor de los Usuarios, con el cual podamos crear Roles y Usuarios desde CRUD’s elaborados por el mismo framework y crear nuestro propio esquema de seguridad, debo resaltar que existen muchos Bundles prefabricados como el FOSUserBundle que facilitan enormemente ésta tarea, pero si quieres profundizar puedes seguir el siguiente tutorial para conocer a fondo como se hace desde 0 con Doctrine .

Paso 1: Crea las entidades básicas
Antes de empezar debemos de definir las entidades básicas para ser utilizadas como proveedor de usuarios y roles en Sf2, dichas entidades User y Role deben de implementar las interfaces Symfony\Component\Security\Core\User\UserInterface y Symfony\Component\Security\Core\Role\RoleInterface respectivamente, así que añade estas 2 entidades a tu directorio “proyecto/src/MDW/BlogBundle/Entity”:

User.php:

<?php
// proyecto/src/MDW/BlogBundle/Entity/User.php
namespace MDW\BlogBundle\Entity;

use Symfony\Component\Security\Core\User\UserInterface;
use Doctrine\ORM\Mapping as ORM;
/**
  * @ORM\Entity
  * @ORM\Table(name="admin_user")
  */
class User implements UserInterface
{
    /**
     * @var integer $id
     *
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    private $id;

    /**
    * @ORM\Column(type="string", length="255")
    */
    protected $username;

    /**
     * @ORM\Column(name="password", type="string", length="255")
     */
    protected $password;

    /**
     * @ORM\Column(name="salt", type="string", length="255")
     */
    protected $salt;

    /**
     * se utilizó user_roles para no hacer conflicto al aplicar ->toArray en getRoles()
     * @ORM\ManyToMany(targetEntity="Role")
     * @ORM\JoinTable(name="user_role",
     *     joinColumns={@ORM\JoinColumn(name="user_id", referencedColumnName="id")},
     *     inverseJoinColumns={@ORM\JoinColumn(name="role_id", referencedColumnName="id")}
     * )
     */
    protected $user_roles;

    public function __construct()
    {
        $this->user_roles = new \Doctrine\Common\Collections\ArrayCollection();
    }

    /**
     * Get id
     *
     * @return integer
     */
    public function getId()
    {
        return $this->id;
    }

    /**
     * Set username
     *
     * @param string $username
     */
    public function setUsername($username)
    {
        $this->username = $username;
    }

    /**
     * Get username
     *
     * @return string
     */
    public function getUsername()
    {
        return $this->username;
    }

    /**
     * Set password
     *
     * @param string $password
     */
    public function setPassword($password)
    {
        $this->password = $password;
    }

    /**
     * Get password
     *
     * @return string
     */
    public function getPassword()
    {
        return $this->password;
    }

    /**
     * Set salt
     *
     * @param string $salt
     */
    public function setSalt($salt)
    {
        $this->salt = $salt;
    }

    /**
     * Get salt
     *
     * @return string
     */
    public function getSalt()
    {
        return $this->salt;
    }

    /**
     * Add user_roles
     *
     * @param Maycol\BlogBundle\Entity\Role $userRoles
     */
    public function addRole(\Maycol\BlogBundle\Entity\Role $userRoles)
    {
        $this->user_roles[] = $userRoles;
    }

    public function setUserRoles($roles) {
        $this->user_roles = $roles;
    }

    /**
     * Get user_roles
     *
     * @return Doctrine\Common\Collections\Collection
     */
    public function getUserRoles()
    {
        return $this->user_roles;
    }

    /**
     * Get roles
     *
     * @return Doctrine\Common\Collections\Collection
     */
    public function getRoles()
    {
        return $this->user_roles->toArray(); //IMPORTANTE: el mecanismo de seguridad de Sf2 requiere ésto como un array
    }

    /**
     * Compares this user to another to determine if they are the same.
     *
     * @param UserInterface $user The user
     * @return boolean True if equal, false othwerwise.
     */
    public function equals(UserInterface $user) {
        return md5($this->getUsername()) == md5($user->getUsername());

    }

    /**
     * Erases the user credentials.
     */
    public function eraseCredentials() {

    }
}

Role.php:

<?php
// proyecto/src/MDW/BlogBundle/Entity/Role.php
namespace MDW\BlogBundle\Entity;

use Symfony\Component\Security\Core\Role\RoleInterface;
use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity
 * @ORM\Table(name="admin_roles")
 */
class Role implements RoleInterface
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

    /**
     * @ORM\Column(name="nombre", type="string", length="255")
     */
    protected $name;

    /**
     * Get id
     *
     * @return integer
     */
    public function getId()
    {
        return $this->id;
    }

    /**
     * Set name
     *
     * @param string $name
     */
    public function setName($name)
    {
        $this->name = $name;
    }

    /**
     * Get name
     *
     * @return string
     */
    public function getName()
    {
        return $this->name;
    }

    public function getRole() {
        return $this->getName();
    }

    public function __toString() {
        return $this->getRole();
    }
}

Una vez creadas nuestras entidades, accedemos a la consola de Symfony2 y generamos las tablas en Base de Datos:

$ app/console doctrine:schema:update --force

Paso 2: Generando los CRUD’s

Una vez creadas las entidades en DB, procedemos a crear los CRUD’s desde la consola de symfony:

$ app/console doctrine:generate:crud

Seguimos los pasos colocando MDWBlogBundle:Role, luego nos solicita si deseamos crear las opciones de escritura, le decimos “y” (sí), formato del CRUD: annotation, y finalmente en el Routes prefix colocamos /admin/role, este paso es importante porque a la ruta le asignamos el prefijo /admin para que nos permita empatar luego con el access_control, confirmamos y aparecerá el mensaje “You can now start using the generated code!”

Procedemos a aplicar lo mismo pero en este caso con MDWBlogBundle:User y en Routes prefix colocamos /admin/user

Ahora añadiremos las rutas a nuestro archivo de rutas (proyecto/src/MDW/BlogBundle/Resources/Config/routing.yml), porque al crearlas como Anotaciones las mismas no se añaden automáticamente:

#proyecto/src/MDW/BlogBundle/Resources/Config/routing.yml
# final del archivo:
MDWAnnotations:
    resource: "@MDWBlogBundle/Controller/"
    prefix:   /
    type:     annotation

De ésta forma añadiremos todas las rutas definidas por anotaciones del directorio Controller, ésta técnica forma parte del SensioFrameworkExtraBundle y nos permite definir las rutas directamente en nuestros controladores. si utilizas la Versión estándar de Symfony2 este Bundle viene por defecto.

Ya con esto podemos acceder a nuestros crud’s desde localhost/proyecto/web/app_dev.php/admin/user, pero aún debemos modificar ciertos aspectos en el controlador User para codificar el hash de contraseña.

Primero añadiremos la siguiente función en el controlador de usuarios:

// proyecto/src/MDW/BlogBundle/Controller/UserController.php
// añadimos esta función
private function setSecurePassword(&$entity) {
	$entity->setSalt(md5(time()));
	$encoder = new \Symfony\Component\Security\Core\Encoder\MessageDigestPasswordEncoder('sha512', true, 10);
	$password = $encoder->encodePassword($entity->getPassword(), $entity->getSalt());
	$entity->setPassword($password);
}

Luego modificamos las funciones de las acciones correspondientes a create y update, añadiendo la llamada al la función anterior para establecer el hash de la contraseña con el algoritmo SHA512:

// proyecto/src/MDW/BlogBundle/Controller/UserController.php

//funcion createAction:
    public function createAction()
    {
        $entity  = new User();
        $request = $this->getRequest();
        $form    = $this->createForm(new UserType(), $entity);
        $form->bindRequest($request);

        if ($form->isValid()) {
            //establecemos la contraseña: --------------------------
            $this->setSecurePassword($entity);

            $em = $this->getDoctrine()->getEntityManager();
            $em->persist($entity);
            $em->flush();

            return $this->redirect($this->generateUrl('admin_user_show', array('id' => $entity->getId())));

        }

        return array(
            'entity' => $entity,
            'form'   => $form->createView()
        );
    }
//...
//funcion updateAction:
    public function updateAction($id)
    {
        $em = $this->getDoctrine()->getEntityManager();

        $entity = $em->getRepository('MDWBlogBundle:User')->find($id);

        if (!$entity) {
            throw $this->createNotFoundException('Unable to find User entity.');
        }

        $editForm   = $this->createForm(new UserType(), $entity);
        $deleteForm = $this->createDeleteForm($id);

        $request = $this->getRequest();

        //obtiene la contraseña actual -----------------------
        $current_pass = $entity->getPassword();

        $editForm->bindRequest($request);

        if ($editForm->isValid()) {
            //evalua si la contraseña fue modificada: ------------------------
            if ($current_pass != $entity->getPassword()) {
                $this->setSecurePassword($entity);
            }
            $em->persist($entity);
            $em->flush();

            return $this->redirect($this->generateUrl('admin_user_edit', array('id' => $id)));
        }

        return array(
            'entity'      => $entity,
            'edit_form'   => $editForm->createView(),
            'delete_form' => $deleteForm->createView(),
        );
    }

Por último sólo nos queda eliminar del formulario (src/MDW/BlogBundle/Form/UserType.php) el campo salt el cual no debe ser modificado por el usuario:

<?php
// proyecto/src/MDW/BlogBundle/Form/UserType.php
namespace MDW\BlogBundle\Form;

use Symfony\Component\Form\AbstractType;
use Symfony\Component\Form\FormBuilder;

class UserType extends AbstractType
{
    public function buildForm(FormBuilder $builder, array $options)
    {
        $builder
            ->add('username')
            ->add('password')
            //->add('salt') //No necesitamos que salt sea mostrado ---------------
            ->add('user_roles')
        ;
    }

    public function getName()
    {
        return 'mdw_blogbundle_usertype';
    }
}

Ahora puedes proceder a registrar usuarios y roles, es muy importante que al menos crees los roles “ROLE_ADMIN” y “ROLE_USER” y dos usuarios (uno con un rol diferente) antes de que procedas en aplicar el esquema de seguridad, de lo contrario no tendrás usuario con que loguearte .

Paso 3: Creando el esquema de seguridad
Ahora procedemos a sobreescribir nuestro esquema de seguridad (proyecto/app/config/security.yml), recomiendo que antes de hacerlo guardes una copia del security.yml.

# proyecto/app/config/security.yml
security:
    encoders:
        MDW\BlogBundle\Entity\User:
            algorithm: sha512
            encode-as-base64: true
            iterations: 10

    providers:
        user_db:
            entity: { class: MDW\BlogBundle\Entity\User, property: username }

    firewalls:
        dev:
            pattern:  ^/(_(profiler|wdt)|css|images|js)/
            security: false

        login:
            pattern:  ^/admin/login$
            security: false

        secured_area:
            pattern:    ^/admin/
#            http_basic:
#                realm: "Introduzca Usuario y Contraseña"
            form_login:
                login_path: /admin/login
                check_path: /admin/login_check
            logout:
                path: /admin/logout
                target: /

    access_control:
      - { path: ^/admin, roles: ROLE_ADMIN }

Como puedes apreciar en “encoders” se ha definido un codificador especifico para la entidad User, utilizando el algoritmo SHA512, además codificandolo en Base64 con 10 iteracciones, tal cual se apreció en la función setSecurePassword del controlador.

En “providers” se estableció nuestra entidad User de Doctrine, especificando el campo correspondiente al username, es cual es el mismo username en nuestra entidad.

En “firewalls” se ha añadido la nueva regla (o firewall) login desde la cual se aplica el parametro security: false lo que permite acceder a la misma sin autenticarse, de lo contrario el formulario de login nunca lo podremos visializar.

Además en “secured_area” se ha eliminado anonymous, se ha establecido “form_login” donde definimos la ruta para el login del sistema, y se definió una ruta personalizada para el “log_out“, donde en “target” podemos definir el path hacia donde redirigir cuando los usuarios cierren sesión.

Para culminar sólo necesitamos crear el controlador y vista para nuestro login, por lo que debes de crear el archivo SecurityController.php en el directorio (proyecto/src/MDW/BlogBundle/Controller):

SecurityController.php

<?php
// proyecto/src/MDW/BlogBundle/Controller/SecurityController.php
namespace MDW\BlogBundle\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Method;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Template;
use Symfony\Component\Security\Core\SecurityContext;

/**
 * Security controller.
 *
 * @Route("/admin")
 */
class SecurityController extends Controller
{
    /**
     * Definimos las rutas para el login:
     * @Route("/login", name="login")
     * @Route("/login_check", name="login_check")
     */
    public function loginAction()
    {
        $request = $this->getRequest();
        $session = $request->getSession();
        // obtiene el error de inicio de sesión si lo hay
        if ($request->attributes->has(SecurityContext::AUTHENTICATION_ERROR)) {
            $error = $request->attributes->get(SecurityContext::AUTHENTICATION_ERROR);
        } else {
            $error = $session->get(SecurityContext::AUTHENTICATION_ERROR);
        }
        return $this->render('MDWBlogBundle:Security:login.html.twig', array(
            // el último nombre de usuario ingresado por el usuario
            'last_username' => $session->get(SecurityContext::LAST_USERNAME),
            'error'         => $error,
        ));
    }
}
?>

Ahora crea el directorio “Security” dentro de (proyecto/src/MDW/BlogBundle/Resources/views) y procede a crear el archivo de vista:

login.html.twig

{# proyecto/src/MDW/BlogBundle/Resources/views/Security/login.html.twig #}
{% if error %}
<div>{{ error.message }}</div>

{% endif %}
<form action="{{ path('login_check') }}" method="post"><label for="username">Username:</label>
 <input id="username" type="text" name="_username" value="{{ last_username }}" />
 <label for="password">Password:</label>
 <input id="password" type="password" name="_password" />

 <input type="submit" name="login" />
</form>

Y con ello ya puedes intentar acceder a localhost/proyecto/web/admin/user y probar el sistema de seguridad de Symfony2 (vaciar la caché en el caso de entrar al entorno de producción), si creaste previamente 2 usuarios, intenta acceder con el usuario que no tiene el rol “ROLE_ADMIN” y verás como te niega el acceso, en cambio si pruebas con un usuario con dicho rol, puedes entrar perfectamente.

Resumen Final

En esta ocasión apreciamos el complejo sistema de seguridad de Symfony2, en donde un firewall verifica si el usuario está o no logueado, y un access control vigila que dicho usuario no pueda acceder a contenido del cual no se le ha dado acceso, también conocimos que se pueden definir providers diferentes para contener a nuestros usuarios y encoders para personalizar el HASH de la contraseña.

Además interactuamos con dicho sistema a través de un “rápido” tutorial que nos permitió resolver las inquietudes más directas en cuanto a creación de un básico RBAC (Role-based Access Control), reitero que no es la única forma de hacerlo y que existen muchos Bundles Prefabricados como el FOSUserBundle que nos facilita enormemente ésta tarea, pero si no se conoce debidamente la base puede resultar una verdadera caja negra el usar un Bundle sin el previo conocimiento de como Symfony2 implementa tales mecanismos.

Maycol Alvarez para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Un hombre en Boston jugaba a la bolsa de valores exitosamente, pero un día se le presentó un gran desafío: enseñarle algebra a sus sobrinos. Como todos nos imaginamos, la forma más eficiente para lograrlo, era contando una historia mientras dibujaba en una pizarra digital y lo compartía en youtube. Así es, el mismo youtube donde vos y yo hemos perdido tanto el tiempo viendo memes y videos musicales.

Con el tiempo, Khan Academy en su canal de youtube ha reproducido más de 151 millones de lecciones en vídeos que te enseñan desde álgebra, finanzas, historia y tecnología. La fundación Bill & Melinda Gates junto a otros notables inversionistas les dieron suficiente dinero para que intenten cambiar el mundo educándolo mejor. Han recibido aportes de más de 7 millones de dólares a la fecha. Les recomiendo la charla de Salman Khan en Ted que nos cuenta más del proyecto.

Javascript como base de la plataforma

Uno de los héroes que se unió a este cometido es John Resig. Si no sabes quién es, digamos que el ayudó a crear el framework de jQuery, del que seguramente has copy&pasteado más de algún código para ponerle alguna funcionalidad al frontend de tu sitio web. Resig, se dedica a crear tecnología para esta universidad del futuro. Me pregunto si este esfuerzo logrará erradicar la fórmula que BlackBoard (como software propietario) y Moodle (como software libre) han implementado en miles de centros universitarios. Centros que venden una educación virtual que sigue sin cambiar el mundo. Y otro punto importante del apoyo de Resig es que está impulsando desde Khan que Javascript sea el primer lenguaje que aprenden muchos estudiantes a programar.

Khan Academy va a seguir generando y curando contenido, está desarrollando una plataforma para organizar e impartir mucho mejor sus cursos y además tendrá muy pronto parqueos, sanitarios y cafetería. El mundo de la educación virtual convierte en tangible un espacio donde están comprometidos a enseñar. La marca y el financimiento que ha obtenido le da suficiente fuerza para luchar sola aunque siempre quedamos inquietos de las posibles alianzas con otras universidades.

Sumergirse en Khan Academy es una experiencia recomendada para los que nos gusta repasar finanzas y algo de álgebra en el tiempo libre. El proyecto se ha ganado bastantes detractores que cuestionan si realmente es el modelo revolucionario que todos esperamos, pero son palabras, no propuestas. Envidia la dicen por mi tierra.

¿La educación es un negocio de bienes raices?

Al inicio de este post cuestionaba sobre la razón de los ladrillos que están comprando para construir un campus físico. Cuando mueves muchos millones hay que justificar el plan y muchos de los asesores pueden tener más conocimiento sobre cómo generar conceptos universitarios ya reconocidos que transformar desde un catálogo de vídeos y nuevas platormas que funcionen online. Si solo fuera un proyecto virtual tal vez la valuación no fuera tan alta, quizá solo haría falta seguir ganando de publicidad de las impresiones de los videos.

Sigo sin entender las razones por las que Khan Academy tendrá una universidad física, en mi cabeza sigue sin necesitarla, pero espero que cuando la llegue a visitar, que en lugar de estatuas y monumentos de científicos y notables personajes de la historia, que la estatua en la entrada sea de los sobrinos de Khan. Son los verdaderos heroes de esta nueva universidad.

- En un próximo artículo de esta serie de educación virtual, hablaremos de Codecademy. Nos leemos mañana.

Síguenos en: @maestros | Fan page

Vistas

Un función de vista o una vista, como es conocida generalmente, es una función en Python que hace una solicitud Web y devuelve una respuesta Web, esta respuesta puede ser el contenido de una página, un error 404, una imagen, un documento XML, entre muchas cosas más.

La vista contiene toda la lógica necesaria para devolver una respuesta, todas estas respuestas se encuentran en un único archivo y este archivo se llama: views.py, que se encuentra dentro de cada aplicación de Django.

Las consultas y las vistas

En el capítulo anterior, jugamos con algunas consultas, estas consultas son parte fundamental de las vistas, permiten elegir que tipo de contenido se visualizará. Revisa y practica, si no lo hiciste, para poder obtener mejores resultados.

Las plantillas y las vistas

Las plantillas son muy importantes, permiten acomodar el resultado que devuelve la vista. Django tiene un estupendo motor de plantillas que permite separar eficientemente la presentación, de la lógica de programación, esta semana trabajaremos con algunas plantillas simples para no causar confusión.

Proyecto de ejemplo: las vistas

Para esta semana debemos tener en cuenta que nuestros modelos almacenados en models.py dentro de la aplicación principal, quedaron así:

models.py recetario

Rellenamos algunos datos para poder tener resultados:

Django admin dashboard

Django admin, agregar usuarios

Django admin, agregar recetas

Con estos datos empezaremos a hacer algunas vistas para nuestro proyecto. Empezaremos con las importaciones necesarias, que son estas:

Django views.py import

La primera de ellas es porque necesitamos los modelos, la segunda línea para poder usar los datos del modelo usuario, la tercera línea es la respuesta más simple (HttpResponse), la cuarta importa: render_to_response (para las plantillas) y get_object_or_404 (para lanzar un error 404, de no encontrar ningún valor almacenado) y la quinta línea importa el RequestContext (en este caso para poder usar la ruta de las imágenes almacenadas previamente en la carpeta carga y referenciadas por la url media).

Ahora pasemos a ver donde usamos específicamente cada uno de estos componentes.

Vista: sobre

Esta vista es un ejemplo muy simple del uso de HttpResponse, está devolviendo el contenido HTML:

vista sobre

Debemos tener en cuenta que siempre debemos acompañar una vista de su configuración en urls.py, así que en este archivo debemos tener esta línea: (ubicada dentro de patterns)

url(r'^sobre/$','principal.views.sobre'),

Lanzamos nuestro servidor de desarrollo:(como todas las semanas)

python manage.py runserver

Y vamos a la dirección:
http://127.0.0.1:8000/sobre/

vista sobre en el navegador

Vista: Inicio

vista inicio

La vista inicio, hace una consulta de todas las recetas y las almacena en una variable llamada recetas (también), es aquí donde es apropiado usar render_to_response para poder indicarle que vamos a usar la plantilla inicio.html, y que le pasaremos en un diccionario (concepto de python), el resultado de la consulta.

La plantilla inicio.html debemos crearla en la carpeta ‘plantillas’ que se encuentra en ‘recetario’ (creada previamente en capítulos anteriores), su contenido debe ser similar al siguiente:

inicio.html

Veremos unos símbolos {% %} que por no deben distraernos, así que no entraré en detalles al respecto, pueden intuir de que trata, pero prefiero no confundirlos y dejarlos para la próxima semana.

Ahora igual que el ejemplo anterior debemos agregar la siguiente línea en nuestra configuración de las url en urls.py:

url(r'^$','principal.views.inicio'),

Nuestro servidor debe estar funcionando y podemos ingresar a la siguiente dirección:

http://127.0.0.1:8000/

inicio.html

Vista: usuarios

Esta vista saca los datos de los usuarios registrados, y las recetas registradas. Y repite el mismo procedimiento de la vista anterior.

vista usuarios

La plantilla usuarios.html debe ser creada en la carpeta plantillas y debe tener un contenido similar al siguiente:

usuarios.html

En esta plantilla se estan juntando a los usuarios y sus respectivas recetas, agregamos la siguiente regla al urls.py:

url(r'^usuarios/$','principal.views.usuarios'),

para ver el resultado (servidor corriendo), debemos entrar a:

http://127.0.0.1:8000/usuarios/

Resultado de la vista usuarios

Vista: lista_recetas

vista lista_recetas

Esta vista, se diferencia de las anteriores por el uso de context_instance=RequestContext(request), usada para indicarle a la plantilla el parámetro {{MEDIA_URL}} que referencia a la ruta de las imágenes, la plantilla recetas.html, debe quedar así:

Resultado de la vista lista_recetas

La línea en urls.py debe ser así:

url(r'^recetas/$','principal.views.lista_recetas'),

Y se deben visualizar los resultados en:

http://127.0.0.1:8000/recetas/

Resultado de la vista lista_recetas

Vista: detalle_receta

vista detalle_receta

Esta vista recibe un parametro mas: id_receta, que le sirve para hacer una consulta del detalle de esa receta (corresponde a su llave primaria) y usa get_object_or_404(Receta, pk=id_receta), para obtener un objeto o un error 404 en caso de no encontrar resultado alguno.

Con este resultado, se realiza una consulta para obtener sus comentarios. La plantilla receta.html, quedará así:

receta.html

La línea en urls.py debe ser así: (notar las expresiones regulares en python)

url(r'^receta/(?P<id_receta>\d+)$','principal.views.detalle_receta'),

Y se deben visualizar los resultados al darle clic en los enlaces a recetas en:

http://127.0.0.1:8000/recetas/

receta: huevito frito

receta: agua hervida

receta: limonada

Archivo final: views.py

Al final de todo, views.py debe quedar de esta manera:

views.py

Archivo: urls.py

El archivo urls.py, permite tener unas urls limpias, para nuestro ejemplo este debe quedar de la siguiente manera: (si fuiste impaciente, regresa a la vista: sobre )

urls.py

Para finalizar, si se perdieron con alguna línea o si desean corroborar que todo va bien, pueden estar pendientes del repositorio del proyecto.

La próxima semana veremos el tema de las plantillas con un poco más de detalle, practiquen haciendo sus propias vistas, usando las consultas que aprendieron en el capítulo anterior y complementen lo aprendido con un vistazo a la documentación oficial, que nunca esta demás. Que tengan buen inicio de semana .

Sergio Infante Montero para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Durante ese tiempo, quedé enamorado con la idea de tener un rol en las aulas. Desde muy joven me asigné un nombre que siempre me ha costado llevar en la espalda: Maestros… ¿Maestro del Web? Yo estaba aprendiendo, sigo aprendiendo; enseñar y compartir es una excusa para hacer la tarea. No hay mejor alumno que el que tiene que aprender a la fuerza con el deadline y compromiso de que va a compartir algún tema en clase.

La educación virtual se definió como el uso de las TIC´s en el modelo de aprendizaje que se acopla al tiempo y necesidad del estudiante. Esa educación adquirida en la experiencia y cursos que se imparten fuera del salón de clases, pero que el profesor puede ser un tutor que utiliza el internet como plataforma para impartir conocimiento.

Sin embargo, la educación virtual se ha utilizado falsamente en la batalla por expandir la base de usuarios de centros universitarios y lamentablemente, también para vender una experiencia más pasiva de educación con libertad de horarios, espacios y agenda. La educación virtual es visto como uno de los espacios donde menos se compromete el alumno a estudiar, concretar resultados, aprender un tema y finalmente generar un cambio en el mundo.

Re-definiendo Educación Virtual

Hoy estamos intentando re-definir la educación virtual desde muchos frentes. Universidades tan populares en el mundo como Stanford, Harvard, Yale, Cornell, MIT y demás, están en la apuesta. Queremos entender qué paso con Oxford, Cambridge, Tec de Monterrey, UBVirtual, Palermo, etc. Más importante aún, en el entorno web surgieron otros nombres en poco tiempo: Khan Academy, Codecademy, Udacity o Coursera.

¿Saben quiénes están también en la lista sin que muchos se den cuenta? Youtube (y por ende Google), Facebook, Wikipedia, Facebook, LinkedIn (hey, ahora tienen a Slideshare) y nuestras comunidades: Foros del Web y Cristalab, también están allí desde hace años.

Re-definamos la educación y lo que pasa en Internet, porque cualquier servicio, espacio digital, comunidad o red social puede potenciarse como plataforma para educar a los demás. Puede utilizarse para educar y mercadearse, sin que el capitalismo de esta estrategia sea mal visto hasta por los más izquierdosos del planeta.

A lo largo de este año, voy a compartir con ustedes un análisis de los servicios, las plataformas, las estrategias y los miles de proyectos que hacen que el llamado mundo de la “Educación Virtual” demuestre sus verdaderos colores, esos donde no tenemos aún nada claro, pero muchos estamos invirtiendo tiempo en descubrir o re-descubrir.

¿Te interesa la educación virtual?

Si participas en esta industria, si te apasiona el tema, charlemos. Estamos en la búsqueda de ampliar nuestro equipo, estamos en busca de alianzas, queremos críticas sinceras.

Si el mundo digital modificó por completo, sin vuelta atrás, el mundo de la música, el vídeo, el entretenimiento y lo sigue haciendo con el comercio y la creación de empresas de servicios. La educación sigue esperando su momento de gloria, donde esa misma materia digital transmite profesiones universales sin importar las distancias de los grandes maestros e investigadores. Espero me acompañen en la aventura.

En un próximo capítulo de la serie exploraremos a Khan Academy.

Síguenos en: @maestros | Fan page

Organizar un evento en donde tienes conferencistas internacionales, expertos en sus áreas y contenido de gran valor no es tarea fácil. La logística empieza con encontrar una sede accesible para los participantes, entender el mercado, conocer la audiencia y las dinámicas culturales. No es lo mismo organizar un evento en Chile que hacerlo para México. La logística en Argentina es muy diferente de la logística en Colombia. Son muchos los factores que debes contemplar y sobre todo, saber que tu audiencia está interesada y quiere participar.

¿Qué se necesita para un evento Mejorando.la/conferencia?

Mejorando.la/conferencia es un evento global, es lo más importante de entender, que la sede esté en tu país no significa que sólo los asistentes de la sede estén presentes en el evento, en realidad en nuestra última transmisión logramos que más de 50 mil personas estuvieran conectadas durante 2 días en la serie de conferencias que preparamos para el evento. Así, que no estamos organizando un evento sólo para las 200 o 500 personas en un salón, estamos organizando un evento para 50 mil personas más fuera de ese salón.

Sin embargo, que la transmisión sea desde un país o región en específico es una gran oportunidad para que profesionales destacados locales muestren lo que está sucediendo en su país. Además, tendrán la oportunidad de conversar con los conferencistas extranjeros, aprovechar el networking y casi siempre, logramos que los participantes se vayan con premios o regalos de los patrocinadores. Entonces dejenme compartirles las piezas que necesitamos ir armando para lograr que el próximo evento de mejorando.la/conferencia sea transmitido desde Centroamérica para el mundo.

• Participación: Es muy importante detectar el interés de la audiencia en el país o región. Saber si el lugar seleccionado permitirá que personas de la región viajen al lugar del evento. Desafortunadamente no podemos estar en todos los países, pero sí podemos escoger una Ciudad que sea accesible a muchos más.
• Patrocinadores: Tenemos diferentes rangos de patrocinadores, como sabrán el traer conferencistas y hospedarlos cuesta dinero. Además, la sede en ocasiones es un patrocinio y en otras ocasiones debemos pagarla, el internet también es un servicio que debe pagarse y no siempre las empresas del país están interesadas en patrocinar con ese servicio. Otros patrocinadores nos dan de sus productos para regalar y otros patrocinan con su servicio.
• Conferenciastas: Debemos seleccionar cuidadosamente a los conferencistas, saber qué temas quiere la audiencia, conocer el mercado y lo que les interesa. Además, cuando pensamos en conferencistas muy populares en el medio, su agenda es complicada y debemos garantizarnos un espacio. En este tipo de conferencias se le cubren todos los gastos al conferencista y eso también cuesta dinero.
• Sede/Lugar: Como les comenté, en ocasiones se patrocina la sede, pero en otras simplemente el mercado no ofrece muchas opciones y debemos acudir a alquilar el lugar. Gestionar sus servicio y costos de todo: sillas, mesas, luz, conexiones y el doloroso servicios de Internet que en Latinoamérica siempre será un tema difícil.
• Promoción: Tenemos nuestros canales en donde informamos sobre nuestras actividades, en ocasiones blogger influyentes del lugar también hacen mención e invitan a participar. Las redes sociales y nuestras cuentas también las usamos para promover. Pero, también hemos tenido patrocinio de medios del país, empresas interesadas en que el evento suene en los medios tradicionales y sabemos que también es importante estar allí.
• Staff: Siempre contamos con el apoyo de la comunidad, personas que llegan y nos ofrecen su tiempo o por lo menos orientarnos de cómo funcionan las cosas en su país. Tener personas locales siempre es de gran ayuda, porque nos gusta entender cómo funcionan los mercados, entenderlos y brindar lo mejor de nuestro trabajo.

Parecerá que en estos 6 puntos son fáciles de lograr, pero debo recordarles que son mucho matices en cada uno de ellos. Traté de simplificar para exponerles nuestro interes por hacer un evento en Centroamérica, pero que sin duda no lo podemos lograr sin la ayuda, el interes y colaboración de ustedes. Si están interesados en hacer que esto sea posible, les pregunto ¿en cuál de estos 6 puntos nos quieren apoyar? nos interesa sumar esfuerzos y seguir promoviendo la tecnología, el talento y los proyectos que existen en la región hispana para el mundo. Feliz fin de semana. Enjoy!

Stephanie Falla Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Lo que esta ahora sucediendo en la casa del Embajador de Estados Unidos en México pasara a la historia como un momento clave para el emprendimiento en Latino América – Cesar Salazar – Cofundador de Mexican.vc

Estoy completamente de acuerdo con Cesar, pero creo que no solo ha sido ese momento lo que ha marcado un hito en el ecosistema de emprendimiento de América Latina; ha sido el esfuerzo colectivo de todas las diferentes iniciativas de emprendedores de Latino América durante un periodo de 5 años que ha logrado que estemos ahora pasando por una de las mejores etapas en países como México, Chile, Colombia, Argentina y Brasil.

Como todo, no siempre los primeros exploradores han sido los que han recibido el mérito y el reconocimiento que se merecen, estoy hablando de gente como Tomas Pollak, Nicolas Orellana, Leo Prieto, Juan Francisco Diez, Adan Vecindad, Carlos Mondragon, Santiago Siri, Damian Voltes, Ivan Sosa, Juan David Vargas y muchos otros que han tenido éxito en sus emprendimientos, pero a pesar de ello tenemos que reconocer que nunca hemos dejado de ser un “grupo de geeks” o “frikis” con ganas de cambiar el mundo.

El esfuerzo de plantar la semilla emprendedora esta dando sus frutos con Startups como Welcu, Yogome, Fontacto, Ovia, PreyProject, Frogtek y muchas otras mas que tienen a emprendedores Latino Americanos como fundadores.

Miami como punta de lanza para conectar con Hispanos en Estados Unidos.

Quede muy impresionado con la versatilidad de esa ciudad, a pesar de tener la etiqueta de “turística”; esta haciendo un esfuerzo para hacer uso de lo mejor que tiene: una conexión con dos mundos dentro de un mismo país – contacto con la población inmigrante latina y anglosajona de Estados Unidos.

Nadie conoce mejor a la población hispana en Estados Unidos  y Latino Americana que la comunidad de Miami – Adriana Cisneros – CEO de Corporativo Cisneros.

Sin embargo aunque esta ofreciendo muchos incentivos por parte de la Asociación de Empresarios del Condado de Miami y varios grupos de Meetups de Tecnología; no vi un hub de talento para alimentar tu Startup. Esta es una pieza fundamental para cualquier empresa tecnológica pueda crecer en un mercado tan demandante como el de Internet, esto no lo vi reflejado en este viaje; espero en algún momento regresar con mas tiempo para tener esto mas claro.

Definitivamente hay capital en la ciudad, aunque no veo que sea un capital inteligente en el sentido que tenga la experiencia de fondear Startups y entiendan la tolerancia al riesgo que se requiere de un inversor en tecnología. Esto no quiere decir que no se pueda recibir inversión de capital riesgo o algún business ángel, en años venideros aterrizaran muchas empresas Latino Americanas en aquella hermosa ciudad que nos hechiza con sus playas y su ambiente Latino que se respira en cada esquina.

Miami será una excelente opción cuando lleguen a tener suficientes Startups y empresas de tecnología en los alrededores para poder auto-abastecerse para que entre ellas mismas se puedan sustentar; sobre todo la necesidad de talento que requiere un ecosistema de emprendimiento tecnológico.

StartupWeekend Mexico DF, el pais Azteca despertando el interes de geeks de Silicon Valley.

Algo que se ha venido trabajando desde el 2009 con el primer evento de emprendimiento en la Ciudad de Mexico por parte de la iniciativa de iWeekend, varias reuniones de hackers Mexicanos como el SuperHappyDevHouse y MobilecampMX. Ha culminado con 4 eventos de StartupWeekend en México (Guadalajara, Aguascalientes, Morelia y Tijuana) con rotundo éxito y que se proyecta hacer más de 15 en todo el país.

Lo que hace memorable esta tercera edición de México DF sea espectacular, es que tuvo un jurado estelar con figuras como David Weekly, Dave McClure, Allen Taylor, e integrantes de GeeksOnAPlane y mas juzgando a 11 proyectos con un potencial de primer nivel. Se reunieron los líderes de todas la comunidades de tecnología de México desde Guadalajara hasta San Luis Potosí, trajeron a su mejor talento y se vio claro en lo que son los 3 primeros lugares del evento.

Estamos buscando proyectos que podamos fusionar con Startups en SiliconValley y el ganador de StartupWeekend tiene muchas sinergias con TaskRabbit una empresa de nuestro portafolio – Dave McClure hablando de Encarguitos.

Con el primer lugar que fue Encarguitos, así como Legal You (2do lugar) se vio claro como se pudo identificar una necesidad a nivel global, poder ejecutar a nivel local y como poderla escalar de manera orgánica. Esa fue la propuesta de valor que tuvo Encarguitos, que merecidamente ganaron en StartupWeekend México DF.

Me llamo la atención Instareal que es una app para colocar bienes inmuebles de manera sencilla y sindicalizarlos en varias plataformas de búsqueda de bienes raíces. La mención honorífica de RockMob fue para una app que te ayuda a poder quitar la “frustración” de aprender a tocar un instrumento musical y pudieron hacer una demostración en vivo para que alguien pudiera tocar una guitarra.

Convivencia de emprendedores, hackers e inversores en América Latina.

Lo mejor que esta haciendo Geeks On A Plane, es habilitar eventos donde se reúne gente clave de las diferentes comunidades y provoca que puedan establecer una conexión que aunque sea momentánea, tenga el potencial de habilitar futuras conversaciones. Hemos visto eventos como Traweln y La Red Innova que han permitido mediante conferencias hacer estas conexiones en Chile y España, con representación por parte de iniciativas Ibéricas como Digital Asset Deployment (DAD – fondo de inversión) y Smartup (firma de marketing digital).

Ya que en un periodo de 10 días sabemos que la intimidad de compartir cuartos de hotel, comidas, cenas, almuerzos y como no, algunas bebidas “refrescantes” permitirá generar la confianza necesaria para que se pueda trabajar en futuros proyectos.

La confianza que genera un emprendedor en el inversor, es la misma que tiene que generar un fondo de inversión con sus inversores. Es una pieza clave para que cualquier ecosistema de emprendimiento pueda florecer a pesar esta crisis global que se esta viviendo; por eso es clave encontrar a estas “figuras de confianza” para crearlo – Paul Ahlstrom – fundador de Alta Ventures.

Así que no se pierdan lo que se publica diariamente en el hashtag #GOAP en twitter para estar al tanto de lo que acontece en esta gira por Latino America de los Geeks On A Plane.

Síguenos en: @maestros | Fan page

En este capítulo nos concentraremos en la instalación de uno de los Bundles más atractivos para incluir en nuestros proyectos, se trata del StofDoctrineExtensionsBundle por Christophe Coevoet el cual hace una implementación del complemento Doctrine2 behavioral extensions creado por Gediminas Morkevicius, cuyo propósito es proveer de los aclamados Comportamientos (behaviors) de Doctrine; en general explicaremos la configuración de 3 comportamientos ampliamente utilizados, como lo son Timestampable, Sluggable y Loggable, reiteramos que el objetivo del capítulo es la instalación de Bundles de Terceros en Symfony2 y no el de profundizar en todos los comportamientos que provee el StofDoctrineExtensionsBundle.

Paso 1: Instalando el Bundle

En Symfony 2 existen varias formas para la instalación de los bundles de terceros, entre ellas (y la más práctica) es la instalación por medio de submodule en GIT, si no sabes que es GIT te recomiendo visitar http://progit.org/book/es/ y tratar de instalarlo en tu sistema.

Comenzamos instalando la librería principal de Doctrine Behavioral Extensions, para ello accedemos a nuestra consola, nos ubicamos en la raíz del proyecto de symfony y ejecutamos:

~$ git submodule add git://github.com/l3pp4rd/DoctrineExtensions.git vendor/gedmo-doctrine-extensions

Ahora si añadimos el StofDoctrineExtensionsBundle:

~$ git submodule add git://github.com/stof/StofDoctrineExtensionsBundle.git vendor/bundles/Stof/DoctrineExtensionsBundle

Registramos los Namespaces en nuestro app/autoload.php:

<?php

use Symfony\Component\ClassLoader\UniversalClassLoader;
use Doctrine\Common\Annotations\AnnotationRegistry;

$loader = new UniversalClassLoader();
$loader->registerNamespaces(array(
    'Symfony'          => array(__DIR__.'/../vendor/symfony/src', __DIR__.'/../vendor/bundles'),
    'Sensio'           => __DIR__.'/../vendor/bundles',
    'JMS'              => __DIR__.'/../vendor/bundles',
    'Doctrine\\Common' => __DIR__.'/../vendor/doctrine-common/lib',
    'Doctrine\\DBAL'   => __DIR__.'/../vendor/doctrine-dbal/lib',
    'Doctrine'         => __DIR__.'/../vendor/doctrine/lib',
    'Monolog'          => __DIR__.'/../vendor/monolog/src',
    'Assetic'          => __DIR__.'/../vendor/assetic/src',
    'Metadata'         => __DIR__.'/../vendor/metadata/src',
    // Aquí registramos:
    'Stof'  => __DIR__.'/../vendor/bundles',
    'Gedmo' => __DIR__.'/../vendor/gedmo-doctrine-extensions/lib',
));
// ... resto del archivo

Añadimos el Bundle a nuestro app/AppKernel.php:

<?php

use Symfony\Component\HttpKernel\Kernel;
use Symfony\Component\Config\Loader\LoaderInterface;

class AppKernel extends Kernel
{
    public function registerBundles()
    {
        $bundles = array(
            new Symfony\Bundle\FrameworkBundle\FrameworkBundle(),
            new Symfony\Bundle\SecurityBundle\SecurityBundle(),
            new Symfony\Bundle\TwigBundle\TwigBundle(),
            new Symfony\Bundle\MonologBundle\MonologBundle(),
            new Symfony\Bundle\SwiftmailerBundle\SwiftmailerBundle(),
            new Symfony\Bundle\DoctrineBundle\DoctrineBundle(),
            new Symfony\Bundle\AsseticBundle\AsseticBundle(),
            new Sensio\Bundle\FrameworkExtraBundle\SensioFrameworkExtraBundle(),
            new JMS\SecurityExtraBundle\JMSSecurityExtraBundle(),
            new MDW\BlogBundle\MDWBlogBundle(),
            new MDW\DemoBundle\MDWDemoBundle(),
            // Aquí Añadimos:
            new Stof\DoctrineExtensionsBundle\StofDoctrineExtensionsBundle(),
        );
// ... resto del archivo

Básicamente es todo lo que se realiza para incluir un Bundle.

Paso 2: Configurando el Bundle

En nuestro caso el StofDoctrineExtensionsBundle para funcionar requiere agregar configuración adicional al archivo app/config/config.yml de la aplicación (la mayoría de los bundles pueden detallar tales configuraciones en su documentación), para ello agregamos estos segmentos:

En la sección Doctrine Configuration, añadimos al final el mapping para StofDoctrineExtensions Bundle:

# Doctrine Configuration
doctrine:
    dbal:
        driver:   %database_driver%
        host:     %database_host%
        port:     %database_port%
        dbname:   %database_name%
        user:     %database_user%
        password: %database_password%
        charset:  UTF8

    orm:
        auto_generate_proxy_classes: %kernel.debug%
        auto_mapping: true
        # Añadimos el Mapping para StofDoctrineExtensionsBundle: -------------
        mappings:
            StofDoctrineExtensionsBundle: ~
# ... resto del archivo

Luego añadimos al final del mismo archivo la siguiente configuración:

# Añadimos las configuraciones específicas para el StofDoctrineExtensionsBundle
stof_doctrine_extensions:
    default_locale: en_US
    orm:
        default:
            sluggable: true
            timestampable: true
            loggable: true
            #demás behaviors para activar

Donde default: representa la configuración para todos los entornos, eso quiere decir que puedes añadir una configuración específica para cada entorno.

Paso 3: Utilizando los Comportamientos (Behaviors) en los modelos

En este tutorial nos concentraremos en los comportamientos sluggable, timestampable y loggable, para hacer las cosas más fáciles se recomienda añadir el siguiente Namespace a cada una de nuestras entidades en donde queramos añadir los comportamientos:

// añadimos luego del Namespace de la Entidad:
use Gedmo\Mapping\Annotation as Gedmo;

Algunos Behaviors como Loggable disponen de Entidades propias que requieren crearse en base de datos, para garantizar ello solo debemos ejecutar en consola el comando siguiente, de este modo Doctrine creará las tablas necesarias para almacenar los datos generados por los comportamientos que lo requieran:

~$ php app/console doctrine:schema:update --force

Sluggable: Permite que Doctrine cree automáticamente el “slug” o la típica cadena optimizada para buscadores utilizada comúnmente al indexar artículos de un blog. Para definir el slug debemos tener un campo destino que es donde se almacenará y uno o más campos origen (los Sluggable) de los cuales se construirá el slug y es tan simple como agregar los siguientes Metadatos a nuestros campos del modelo:

    // … dentro de una Entidad
    // Campo origen:
    /**
     * @var string $title
     *
     * @ORM\Column(name="title", type="string", length=255)
     * @Gedmo\Sluggable()
     */
    private $title;

    // … otras variables

    // Campo Destino:
    /**
     * @var string $slug
     *
     * @ORM\Column(name="slug", type="string", length=255)
     * @Gedmo\Slug(style="camel", separator="_", updatable=false, unique=true)
     */
    private $slug;
    // … dentro de una Entidad

Note que el campo desde donde se creará el slug ($title) tiene el Metadato @Gedmo\Sluggable(), de hecho puede definir más de uno. En cambio el campo de destino ($slug) tiene el Metadato @Gedmo\Slug(…) y por convención debe ser uno solo, los argumentos style, separator, updatable y unique son opcionales y se detallan en la documentación propia del autor, en este ejemplo se tiene una forma básica de configuración.

Cada vez que se cree un registro de la entidad, Doctrine automáticamente generará el slug y lo aplicará al campo destino, en el caso de modificaciones depende del valor del argumento updatable.

Timestampable: permite que Doctrine gestione la actualización del Timestamp en campos específicos al realizar operaciones de inserción y/o actualización. Para definir un campo con Timestampable solo debemos añadir el Metadato Gedmo\Timestampable(on=”action”), donde action puede ser created o updated respectivamente.

    // … dentro de una Entidad
    // Campo created:
    /**
     * @var date $created
     *
     * @ORM\Column(name="created", type="date")
     * @Gedmo\Timestampable(on="create")
     */
    private $created;
    // Campo updated:
    /**
     * @var datetime $updated
     *
     * @ORM\Column(name="updated", type="datetime")
     * @Gedmo\Timestampable(on="update")
     */
    private $updated;
    // … dentro de una Entidad

Doctrine automáticamente aplicará un nuevo Date al campo definido on=”create” al crear un nuevo registro de la entidad y actualizará el Timestamp del campo definido on=”update” al actualizar el registro de la entidad.

Loggable: permite que Doctrine lleve un control de Versiones sobre los campos indicados, permitiendo consultar las versiones y revertir hacia una versión anterior.
Para crear campos con log (control de versión) solo debemos añadir a cada campo el Metadato @Gedmo\Versioned(), además de añadir el Metadato @Gedmo\Loggable() a la Entidad correspondiente:

// ... encabezados del archivo
// definimos el Metadato @Gedmo\Loggable() a la Entidad:
/**
 * MDW\BlogBundle\Entity\Articles
 *
 * @ORM\Table()
 * @ORM\Entity(repositoryClass="MDW\BlogBundle\Entity\ArticlesRepository")
 * @Gedmo\Loggable()
 */
class Articles
{
    // … dentro de una Entidad
    // Campo $content será Versionable:
    /**
     * @var text $content
     *
     * @ORM\Column(name="content", type="text")
     * @Gedmo\Versioned()
     */
    private $content;
    // … demás contenido de la entidad

Doctrine automáticamente supervisará los updates hacia los atributos marcados como Versioned de  la entidad y llevará un control de versiones en la Entidad (Stof\DoctrineExtensionsBundle\Entity\LogEntry), y gracias al Repositorio de dicha entidad (\Gedmo\Loggable\Entity\Repository\LogEntryRepository) podremos consultar las Versiones e incluso Revertir los cambios (función $logRepositoryInstance->revert($Entity, $version);), aquí apreciamos un ejemplo de un controlador que lista los cambios:

    // Ejemplo dentro de un Controller:
    public function updateArticleAction($id) {
      $em = $this->getDoctrine()->getEntityManager();

      $article = $em->getRepository('MDWBlogBundle:Articles')->findOneBy(array('id' => $id));

      $article->setContent('editado');
      $em->persist($article);
      $em->flush();

      $content = '';
      // ver cambios
      $log = $em->getRepository('Stof\DoctrineExtensionsBundle\Entity\LogEntry');
      /* @var $log \Gedmo\Loggable\Entity\Repository\LogEntryRepository */

      $query_changues = $log->getLogEntriesQuery($article); //use $log->getLogEntries() para un result directo
      $changues = $query_changues->getResult();
      /* @var $version Stof\DoctrineExtensionsBundle\Entity\LogEntry */
      foreach ($changues as $version) {
        $fields = $version->getData();
        $content.= ' fecha: ' .
            $version->getLoggedAt()->format('d/m/Y H:i:s') .
            ' accion: "'  . $version->getAction() . '"'.
            ' usuario: "' . $version->getUsername() . '"'.
            ' objeto: "'  . $version->getObjectClass() . '"'.
            ' id: "'      . $version->getObjectId() . '"'.
            ' Version: "' . $version->getVersion() . '"'.
            ' datos:';
            foreach ($fields as $field => $value) {
              $content.= "-- " . $field . ': '. $value . '';
            }
      }
      // generamos una salida básica
      $r = new \Symfony\Component\HttpFoundation\Response();
      $r->setContent($content);
      return $r;
    }

De esta forma podemos aprovecharnos de algunos de los comportamientos más utilizados de Doctrine, reutilizar código y automatizar tareas en nuestros modelos.

Resumen Final

Como pudimos apreciar con Symfony2 disponemos de una amplia variedad de bundles de terceros a incluir para extender las capacidades de nuestras aplicaciones, aprovechar y reutilizar código mejorando considerablemente el tiempo en el desarrollo de nuestros proyectos; aprendimos que existen diversas formas de incluir nuestros bundles y que en dado caso podemos hacer instalaciones a mano, también de lo importante que es seguir la documentación de cada bundle para agregarlo en el Autoload o Kernel según corresponda y aplicar las configuraciones requeridas por el mismo.

Maycol Alvarez para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Los modelos nos van a permitir manipular los datos: registrarlos, editarlos, actualizarlos, consultarlos, eliminarlos y realizar procesos con ellos. Toda está manipulación se reflejará luego en las vistas y posteriormente en las plantillas para mostrar los resultados en el navegador, esta manipulación se le conoce generalmente como: Consultas.

El Shell

El Shell es el interprete interactivo de Python, que nos permitirá probar los modelos, hacer consultas, analizar resultados, antes de elaborar las vistas. Es muy útil si queremos ahorrar tiempo al momento de responder a los requerimientos que los usuarios de la aplicación puedan necesitar.

Para poder acceder a la shell, abrimos una terminal o ventana de comandos, y nos ubicamos en la carpeta de proyecto (en donde se encuentre el archivo manage.py) y digitamos:

python manage.py shell

Debemos visualizar el siguiente resultado:

Shell

Lo importante es reconocer los elementos: el prompt se representa por >>> y el resultado de nuestras instrucciones se visualizarán en nuevas líneas (sin ningún símbolo previo a ellas)

Las consultas

Las consultas en base a los modelos de Django son la base de todo el desarrollo en este framework estas consultas nos pueden permitir saber, por ejemplo, la lista de usuarios, los correos electronicos de los que hacen comentarios, el primero comentario de un artículo, los artículos del mes de mayo, y la lista de posiblidades es larga.

Las consultas están descritas muy claramente en la documentación oficial, para poder hacer esto más simple aquí también usaremos esta pequeña chuleta o cheat sheet como también es conocido.

Django Queryset CheatSheet

La referencia de todos estos métodos se encuentran también en la documentación oficial.

Ejemplos

Ahora pasamos a lo divertido, seguimos trabajando con nuestro proyecto de ejemplo, para poder realizar algunos ejemplos tenemos que modificar y corregir el models.py y dejarlo así: (ya no existe el modelo Bebida, ya no es necesario, también se debe eliminar cualquier rastro del modelo Bebida de admin.py)

models.py

Una vez que tenemos listo el models.py , reiniciamos el modelo (si no recuerdas como reiniciar revisa el capítulo: El modelo de datos)

python manage.py reset principal

Una vez con los modelos listos, es hora de probar el interprete interactivo (shell). No olvidar que la siguiente instrucción se debe lanzar desde el directorio donde se encuentra el archivo manage.py

python manage.py shell

Una vez dentro del shell, empezamos a importar los modelos, para ello digitamos

from principal.models import Receta, Comentario

Esta instrucción importa todo el modelo al shell. Aquí es donde podemos consultar el contenido de los modelos y otras consultas, la sintaxis es del tipo:

Nombre_de_modelo.objects.metodo()

Donde podemos reemplazar Nombre_de_modelo y método por las diversas opciones que están en el cheatsheet (chuleta)

all()

En la imagen vemos como resultado una lista vacia [], entonces vamos a agregar elementos, para ello también necesitamos al modelo usuario que ya lo tiene Django, una vez que lo importamos sacamos al usuario cuya llave primaria (pk) sea 1.

User.objects.get(pk=1)

Ahora si introducimos datos a los modelos: (la r es solo una variable cualquiera)

create()

Y comprobamos que se ha registrado:

Receta.objects.all()

Agregamos un comentario a la receta anterior: (la c es solo una variable cualquiera)

create() en Comentario

Agregamos una receta mas: (Se puede escribir todo en una sola línea, yo lo hago para que se vea bien en la imagen)

create() podría ir en una sola línea

Sigamos jugando, ahora mostraremos las recetas cuyos ingredientes no empiecen con la letra A: (notar que luego de ingredientes hay dos guiones bajos)

exclude y startswith

Ahora las recetas, que mencionen en su preparación la palabra ‘tetera’:

filter y contains

Y si queremos ordenar alfabéticamente por titulo de receta:

order_by()

Ahora lo invertimos:

order_by y reverse

Mostramos los comentarios de cada receta:

filter()

Ahora me gustaría actualizar el titulo ‘Huevo Frito’ a la de ‘Huevito Frito’:

update()

Sigo agregando comentarios a la primera receta y deseo saber cuantos comentarios hay hasta el momento en ambas recetas:

count()

Agrego un comentario a la segunda receta (un comentario troll) y luego lo elimino:

delete()

Ahora deseo saber el nombre de usuario y correo electrónico del usuario que agregó la receta con el título exacto de ‘Agua hervida’:

Todo está orientado a objetos

Como verán hacer consultas en Django es simple, sin embargo siempre es bueno tener la documentación a la mano, ya que recordar tantos métodos puede ser tedioso al principio.

Las consultas son el paso previo a trabajar con las vistas y las plantillas, nos permitirán entregar a los usuarios del proyecto, la información que requieran. El próximo capítulo será: Las vistas.

Práctica tus propias consultas, juega con los modelos, diviértete, que el momento de aplicarlas serán en el próximo capítulo.

Sergio Infante Montero para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Insisto en el tema porque recibo mensajes en redes sociales y correos en donde muchas personas quieren conversar sobre trabajo o sus proyectos pero no tienen un enlace que me brinde toda la información. En este mundo tan conectado la mejor forma de comunicarnos es a través de la síntesis de ideas, claras y puntuales que brinden el mensaje adecuado. Tu portafolio en línea es la mejora carta de presentación profesional, tu reputación digital es tan valiosa como tu reputación profesional y las referencias de trabajo.

El portafolio y la reputación digital

En el mundo web el portafolio y la proyección en las rede sociales es fundamental, debido a que es muy sencillo escribir tu nombre en un buscador, hacernos una idea de tu trabajo y del tipo de persona que eres. Al inicio, la gente creía que en Internet era libre y anónimo con el tiempo las redes sociales nos volvieron más visibles con nombre y apellido de tal forma que hemos construido a lo largo de nuestras cuentas una reputación digital.

• ¿Tienes tu portafolio en la web? Conoce las razones por las que un portafolio en línea es indispensable para todo freelancer e inspirate en una serie de referencias.
• La proyección en redes sociales: Todo comentario, aporte o publicación en la web con tu nombre o nickname se encuentra registrado en los buscadores. Tus cuentas en redes sociales son parte de tu identidad digital y por ello debes comprender cuál es la mejor forma de proyectarse.
• Tips para promover tu trabajo en la web: En otra ocasión compartí sobre la importancia del portafolio y las redes sociales para promover tu trabajo. Pero, también existen algunos tips que expertos en el medio nos han aportado para implementar como el regalar algo a la comunidad.
• Inspírate y diseña tu portafolio: Nunca está de más tener referencias del trabajo de otros, ver cómo lo han logrado los demás y revisar estás fuentes puede ser el primer paso para saber por dónde empezar nuestro proyecto de portafolio de evidencias.

Más portafolios de inspiración

• Wellsriley.com: Wells Rilley, diseñador de experiencias. En su portafolio hace uso de tecnologías, diseño, con información clara y puntual.
• Lahive.co.uk: Steve, diseñador y de una forma muy minimalista nos muestra su trabajo y la información de contacto.
• Attackemart.in: Martin Gaue, con su portafolio simplemente nos hace vivir una experiencia del uso de tecnologías y nos despierta la curiosidad.
• Stedesign.com: Muestra de un portafolio en una sola página, algo que se está poniendo muy de moda y que ahorra una serie de navegación y links.

Debemos superar el curriculum vitae e incursionar en el portafolio de evidencias de nuestra experiencia y capacidad. El conocimiento aplicado, sin duda resulta más atractivo en esta industria en donde necesitamos obtener resultados y menos procesos teóricos para ejecutar proyectos, realizar innovación y ser cada vez más competitivos en el medio. Si aún no tienes un portafolio hoy es un buen momento para inspirarte y empezar un nuevo proyecto, que con el tiempo, tendrá sus beneficios y será más práctico al momento de presentarte como freelancer. Feliz fin de semana. Enjoy!

Stephanie Falla Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Como mencioné anteriormente Symfony2 es un Framework PHP orientado al desarrollo en el servidor, por su parte AJAX es una técnica que se implementa desde el JavaScript (JS) cliente, cuyo único objetivo es realizar las peticiones HTTP desde JavaScript y obtener la respuesta para manipularla directamente, sea añadiéndola al DOM o lo que quieras con JavaScript, por lo cual en dicho caso tanto Symfony2 como PHP sólo pueden detectar si la petición fue realizada por dicha técnica, razón por la cual su implementación es realmente simple; también aclaramos que desde su versión 1.3 el proyecto Symfony ha optado por no apoyar ni integrar ningún Framework JS, debido a que ello queda a elección del programador.

En esta continuación del capítulo anterior elegimos a jQuery como el Framework JS a utilizar para los ejemplos, por ser uno de los más populares y fáciles de implementar, reiteramos que puedes usar el FW JS que desees y queda bajo tu absoluta elección, además aclaro que los ejemplos se concentran en el uso de AJAX con jQuery y que para conservar la facilidad con la que implementen los ejemplos no se usaron modelos reales de doctrine, en su caso arrays multidimensionales, si quieren complementarlos con Doctrine, pueden consultar su capítulo: Configurando nuestra Base de Datos.

Ejemplo 1: Ejecutando una llamada ajax con jQuery

Descargamos el script de la página de jQuery y la guardamos en el directorio web\js\. Para este caso la versión actual es jquery-1.7.2.min.js.

Importamos el archivo dentro del template base que se encuentra en app\Resources\views\base.html.twig:

<!DOCTYPE html>
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
        <title>{% block title %}Welcome!{% endblock %}</title>
        {% block stylesheets %}{% endblock %}
        <link rel="shortcut icon" href="{{ asset('favicon.ico') }}" />
                <script src="{{ asset('js/jquery-1.7.2.min.js') }}"></script>
    </head>
    <body>
        {% block body %}{% endblock %}
        {% block javascripts %}{% endblock %}
    </body>
</html>

Con esto ya tenemos el soporte para jQuery en todas nuestras páginas que hereden mediante Twig a este template.

Ya teníamos la página http://localhost/Symfony/web/app_dev.php/articulos/listar que nos mostraba una lista de artículos de la base de datos por lo que podemos hacer otra que simplemente llame por ajax a esta página y muestre los artículos. Para esto creamos la página ver-articulos que simplemente tendrá una link para cargar por ajax el contenido de la página que contiene la lista de artículos. Como cada vez que necesitamos crear una página hacemos los 3 pasos:

CREAMOS LA RUTA

Agregamos a nuestro archivo routing.yml las siguientes líneas para crear la nueva ruta:

ver_articulos:
    pattern:  /ver-articulos
    defaults: { _controller: MDWDemoBundle:Articulos:verArticulos }

CREAMOS EL ACTION

//Dentro del controlador src\MDW\DemoBundle\Controller\ArticulosController.php agregamos el siguiente action
public function verArticulosAction()
{
        return $this->render('MDWDemoBundle:Articulos:ver_articulos.html.twig', array());
}

Como podemos ver lo único que hace es llamar a la vista que creamos a continuación.

CREAMOS LA VISTA

Creamos el archivo ver_articulos.html.twig dentro de la carpeta src\MDW\DemoBundle\Resources\views\Articulos

{% extends '::base.html.twig' %}

{% block title %}Symfony - AJAX{% endblock %}

{% block body %}

<div id="articulos"></div>
<a id="link_articulos" href="#">Cargar articulos</a>

{% endblock %}

{% block javascripts %}
<script>

$(document).ready(function(){
        $('#link_articulos').click(function(){
                $('#articulos').load('{{ path('articulo_listar') }}');
        });
});

</script>
{% endblock %}

En esta página hemos heredado el contenido de template base con el extend y hemos incluído los bloques. Vemos que en el body lo único que tenemos es un div vacío con id “articulos” y link con id “link_articulos” para obtenerlo utilizamos jQuery. La idea es que al ingresar a la página solo nos muestre el link y no así los artículos. Al dar click sobre el link “Cargar Artículos” se ejecutará una llamada ajax mediante jQuery y cargaremos asincrónicamente la ruta {{ path(‘articulo_listar’) }} que sería la página que ya tenemos lista y que vimos en el capítulo 9 – Manipulando datos con Doctrine.

Entendamos el código jQuery:

<script>

$(document).ready(function(){
        $('#link_articulos').click(function(){
                $('#articulos').load('{{ path('articulo_listar') }}');
        });
});

</script>

Primeramente registramos el evento ready para que ejecute la función anónima una vez que todo el DOM sea cargado.

Una vez ejecutado el evento ready, agregamos una acción al evento click de nuestro link que ejecutará la función que carga la segunda página:

$('#link_articulos').click(function(){
        $('#articulos').load('{{ path('articulo_listar') }}');
});

La función load() de jQuery se ejectua sobre el div vacío para que el resultado de la respuesta Ajax se cargue dentro de este div y como argumento del método pasamos la dirección en donde, para no escribir la URL a mano, usamos la función Twig {{ path(‘articulo_listar’) }} para que los genere la ruta relativa de la ruta articulo_listar.

Con esto ya podemos acceder a la página http://localhost/Symfony/web/app_dev.php/ver-articulos donde veremos un link “Cargar artículos”. Presionando el link veremos como se obtiene, sin recargar la página, el listado de artículos de la base de datos.

Ejemplo 2: Gestionando llamadas AJAX con jQuery, Twig y herencia en 3 niveles

En el ejemplo anterior apreciamos lo sencillo que es implementar una llamada AJAX por medio del FW jQuery y comprendimos que en realidad Symfony2 interviene prácticamente en nada porque su alcance se limita al desarrollo del lado del servidor, en este ejemplo práctico haremos uso de las facilidades que brinda Symfony para detectar peticiones AJAX y modificar la respuesta en función de las necesidades.

Para este ejemplo crearemos una sección o módulo de noticias, en donde nos aparece un listado principal de noticias de las cuales al hacer click nos redirigirá al detalle de la noticia como tal. La idea es conservar un enlace directo a cada noticia, con el cual un motor de búsqueda pueda indexar y a su vez cargar el detalle de la noticia en una capa por medio de AJAX (con load jQuery) con el objetivo de que el usuario pueda cargar las noticias sin recargar la página y si en caso llega desde un buscador pueda apreciar la noticia y el resto de contenidos que ofrezca nuestro layout principal.

Para ello creamos primero nuestro layout:

{# /src/MDW/DemoBundle/views/layout.html.twig #}
{% extends '::base.html.twig'  %} {# extendemos del layout por defecto #}

{% block javascripts %}
{# añadimos la CDN de jQuery o en su defecto lo descargamos e incluimos con:
<script src="{{ asset('js/jquery-1.7.2.min.js') }}"></script>
 #}
<script type="text/javascript" src="http://code.jquery.com/jquery-1.7.2.min.js"></script>
{% endblock javascripts %}

{# creamos una estructura para el layout general #}
{% block body %}
<div>
    <h1>*** Web de Noticias ***</h1>
    {# según el patrón de 3 niveles, creamos el bloque de contenido #}
    {% block content %}{% endblock content %}
</div>
{% endblock body%}

Procedemos ahora a crear las rutas hacia nuestro controlador, abre el src/MDW/DemoBundle/Resources/config/routing.yml y agrega:

# /src/MDW/DemoBundle/Resources/config/routing.yml

MDWDemoBundle_noticias:
    pattern:  /noticias
    defaults: { _controller: MDWDemoBundle:Notice:index }

MDWDemoBundle_noticeView:
    pattern:  /leerNoticia/{notice_id}
    defaults: { _controller: MDWDemoBundle:Notice:noticeView }

Procedemos ahora a crear el controlador, en este ejemplo utilizaremos como Modelo un array de noticias, para enfocarnos en el uso de AJAX:

<?php
// src/MDW/DemoBundle/Controller/NoticeController.php
namespace MDW\DemoBundle\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\Controller;

class NoticeController extends Controller
{
    // tenemos un array con los datos básicos
    private $array_notice = array(
        array(
            'title' => 'Titulo de noticia 0',
            'content' => 'Contenido de noticia 0'
        ),
        array(
            'title' => 'Titulo de noticia 1',
            'content' => 'Contenido de noticia 1'
        ),
    );    

    public function indexAction()
    {
        // suponiendo que obtenemos del modelo el listado de noticias
        return $this->render('MDWDemoBundle:Notice:index.html.twig', array(
            'notices' => $this->array_notice
        ));
    }

    public function noticeViewAction($notice_id)
    {
        //obtenemos la noticia del modelo, en este ejemplo proviene de un array
        $notice = $this->array_notice[$notice_id];
        return $this->render('MDWDemoBundle:Notice:noticeView.html.twig', array(
            'notice' => $notice
        ));
    }
}

Procedemos ahora a crear las vistas principales:

{# src/MDW/DemoBundle/Resources/views/Notice/index.html.twig #}

{% extends 'MDWDemoBundle::layout.html.twig'  %}
{% block content %}
<div>
    <p>Noticias recientes</p>
    <ol>
        {% for index,notice in notices %}
        <li><a href="{{ path('MDWDemoBundle_noticeView', {'notice_id': index}) }}">{{notice.title}}</a></li>
        {% endfor %}
    </ol>
    <div id="notice_viewer">
    {# en esta capa serán cargadas las noticias por ajax #}
    </div>
</div>
{% endblock content %}

{# extendemos el bloque javascript #}
{% block javascripts %}
{{parent()}} {# incluimos las declaraciones de script del layout, como jQuery #}

<script type="text/javascript">
{# añadirmos una función al evento click de todos los enlaces a.notice_link, para
usar AJAX en vez de su comportamiento por defecto #}
$(document).ready(function(){
    $('a.notice_link').click(function(event){
        event.preventDefault(); //cancela el comportamiento por defecto
        $('#notice_viewer').load($(this).attr('href')); //carga por ajax a la capa "notice_viewer"
    });
});
</script>
{% endblock javascripts %}

Como puede notar en index.html.twig se ha extendido el bloque JavaScript para añadir la carga por medio de jQuery.load (AJAX) hacia la capa DIV “notice_viewer”, esto con el objetivo de que si un buscador indexa nuestra página pueda hallar los links íntegros de las noticias sin afectar al SEO, además de que nos permite cargar por AJAX el contenido de nuestras noticias directamente en la capa asignada.

{# src/MDW/DemoBundle/Resources/views/Notice/noticeView.html.twig #}

{# note que en este caso utilizamos el layout de ajax para así no cargar todo el contenido del layout general #}
{% extends app.request.isXmlHttpRequest ? "MDWDemoBundle::layout_ajax.html.twig" : "MDWDemoBundle::layout.html.twig" %}
{% block content %}
<div>
    <h2>{{notice.title}}</h2>
    <p>{{notice.content}}</p>
</div>
{% endblock content %}

Como puede apreciar ahora en noticeView.html.twig se hace una bifurcación de los layouts para cuando se trata de una petición AJAX, en la cual se utiliza el layout principal cuando el enlace es accedido directamente (origen de un buscador, o de un usuario con Javascript desactivado) y al contrario si proviene de AJAX se utiliza un layout especial:

{# /src/MDW/DemoBundle/views/layout_ajax.html.twig #}

{# como puede apreciar, el layout para ajax sólo debe incluir el bloque contenido,
adicionalmente podemos añadir extras #}
<div>
    <strong>Visor de Noticias</strong>
    {% block content %}{% endblock content %}
</div>

De esta forma con Symfony podemos adaptar las respuestas en función de si la petición es AJAX o no, y en este caso devolver sólo el contenido necesario, debido a que en una petición AJAX no es necesario devolver la estructura completa HTML como en una petición normal, sino el fragmento de código que nos interesa.

CONCLUSIÓN

Como bien se explica más arriba, las interacciones Ajax no son parte del framework Symfony ya que para esto usamos JavaScript mientras que Symfony es un framework PHP. Existiendo tantas librerías bien robustas para manejo de Ajax como por ejemplo jQuery, incluímos la que más nos guste y ejecutamos la llamada al ajax. La manera de trabajar con librerías JavaScript en Symfony es simplemente incluírlo como un asset de la misma forma que trabajaríamos con las librerías http://www.tinymce.com o http://lightbox.com. Incluímos el archivo y la programación que hacemos para usarla ya es JavaScript y no PHP.

Maycol Alvarez para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

El Modelo

Un modelo es la representación de los datos de nuestra aplicación. Contiene los campos básicos y el comportamiento de los datos que serán almacenados. Por lo general, cada modelo se convierte en una tabla de la base de datos.

Lo fundamental

• Cada modelo es una subclase de django.db.models.Model.
• Cada atributo de un modelo representa a un campo de una tabla.
• Django automáticamente nos da acceso a la base de datos.

Referencia de los campos

La referencia de la versión actual esta detallada por completo en la documentación del framework, con este recurso podemos elaborar todas las referencias necesarias para el proyecto, sin embargo leerlo por completo puede resultar al principio un poco tedioso.

Para ello siempre es muy útil un cheatsheet o chuleta para poder visualizarlos juntos.

Chuleta - Modelos en Django

Ejemplo de modelo en nuestro proyecto

Vamos con el ejemplo del capítulo para poder entender mejor como va esto del modelo.

Nuestro archivo: models.py de la semana pasada quedó así:

from django.db import models

class Bebida(models.Model):
	nombre = models.CharField(max_length=50)
	ingredientes = models.TextField()
	preparacion = models.TextField()

	def __unicode__(self):
		return self.nombre

Este modelo solo fue un ejemplo para saber cómo funcionaba, ahora redactaré algunas líneas que nos ayudarán a tener un modelo más completo:

#encoding:utf-8
from django.db import models
from django.contrib.auth.models import User

class Bebida(models.Model):
  nombre = models.CharField(max_length=50)
  ingredientes = models.TextField()
  preparacion = models.TextField()

  def __unicode__(self):
      return self.nombre

class Receta(models.Model):
  titulo = models.CharField(max_length=100, unique=True)
  ingredientes = models.TextField(help_text='Redacta los ingredientes')
  prepacion = models.TextField(verbose_name='Preparación')
  imagen = models.ImageField(upload_to='recetas', verbose_name='Imágen')
  tiempo_registro = models.DateTimeField(auto_now=True)
  usuario = models.ForeignKey(User)

  def __unicode__(self):
      return self.titulo

Son clases en Python (respetar la indentación), les explicaré de que trata todo esto:

#encoding:utf-8 <- Esta línea permite usar tíldes y caracteres especiales
from django.db import models <- Clase con la descripción de modelos
from django.contrib.auth.models import User <- Llama al modelo usuario

La clase Bebida de la semana anterior sólo era un ejemplo, no le daremos importancia de ahora en adelante, pasemos con la clase Receta (y sus respectivos comentarios previos a cada línea).

#Dato cadena, longitud máxima 100 y único
titulo = models.CharField(max_length=100, unique=True)

#Dato texto, con texto de ayuda
ingredientes = models.TextField(help_text='Redacta los ingredientes')

#Dato texto, con nombre: Preparación
prepacion = models.TextField(verbose_name='Preparación')

#Dato imagen, se almacenarán en la carpeta recetas, titulo: Imágen
imagen = models.ImageField(upload_to='recetas', verbose_name='Imágen')

#Dato Fecha y Hora, almacena la fecha actual
tiempo_registro = models.DateTimeField(auto_now=True)

#Enlace al modelo Usuario que Django ya tiene construido
usuario = models.ForeignKey(User)

La clase Receta (modelo) tiene un atributo imagen, el cuál está direccionando las cargas que haga el usuario a la carpeta ‘recetas’ (carpeta que estará dentro de otra llamada: ‘carga’), para que esto funcione debemos modificar nuestro archivo settings.py, exactamente debemos buscar la línea: MEDIA_ROOT (debe ser la número 56 aproximadamente), y dejarla así:

MEDIA_ROOT = os.path.join(RUTA_PROYECTO,'carga')

Luego de haber puesto esta línea, debemos crear una carpeta que se llame ‘carga’ dentro de la carpeta del proyecto. Debemos tener un árbol de ficheros de este tipo:

Mapa de ficheros del proyecto recetario

Dentro de esta carpeta ‘carga’ aparecerá una carpeta ‘recetas’ al momento de guardar un registro. Pero antes de ello debemos buscar el archivo admin.py y dejarlo asi:

from principal.models import Bebida, Receta
from django.contrib import admin

admin.site.register(Bebida)
admin.site.register(Receta)

Esto nos permitirá agregar el modelo Receta dentro de la interfaz administrativa.

Por último debemos habilitar las URL para poder visualizar las imágenes, para ello debemos dejar el archivo urls.py asi:

from django.conf.urls import patterns, include, url
from django.contrib import admin
from django.conf import settings

admin.autodiscover()

urlpatterns = patterns('',
    url(r'^$','principal.views.lista_bebidas'),
    url(r'^admin/doc/', include('django.contrib.admindocs.urls')),
    url(r'^admin/', include(admin.site.urls)),
    url(r'^media/(?P.*)$','django.views.static.serve',
		{'document_root':settings.MEDIA_ROOT,}
	),
)

Esto nos permitirá acceder a las imágenes que subamos desde http://127.0.0.1:8000/media/recetas/nombre-imagen.jpg (o cualquier otra imagen).

Poniendo a correr todo

Para hacer funcionar todo, debemos sincronizar la base de datos nuevamente (esto se debe hacer cada vez que se modifique el modelo).

python manage.py syncdb

Y esto nos debe mostrar un resultado así (prestar atención a la segunda línea):

python manage.py syncdb

En caso de que queramos modificar un modelo ya existente podemos también reiniciar todos los modelos de la aplicación principal así:

python manage.py reset principal

Sin embargo si ya se tienen datos almacenados estos se perderán al momento de reiniciarlos, para evitar eso podemos usar aplicaciones como South, que nos permitirán trabajar con los datos de manera más profesional. Aquí un video de ejemplo:

Probando el ejemplo

Ya tenemos todo listo, el modelo nuevo sincronizado, las configuraciones listas y la interfaz administrativa. Corremos el proyecto:

python manage.py runserver

Entramos a http://127.0.0.1:8000/admin y debemos observar el nuevo modelo: Recetas, listo para ser usado. Para ver las imágenes que se van cargando podemos ir a http://127.0.0.1:8000/media/recetas/nombre-imagen.jpg y si son proactivos, pueden modificar la plantilla de la semana pasada para poder ver el nuevo modelo de Recetas y sus imágenes, o pueden crear nuevos modelos para ver como pueden interactuar entre sí.

No se olviden que pueden revisar el repositorio del proyecto en github si desean comprobar como deben quedar los archivos (en orden y en contenido).

La próxima semana sabremos que hacer con estos modelos y como interactuar con sus datos, lo haremos a través de la Shell de Django.

Que tengan un buen inicio de semana con Django, no se olviden comentar, twittear y hacer todas sus consultas, para poder ayudarlos.

Sergio Infante Montero para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Con todas estas distracciones del día a día es fácil perder el enfoque, dejar pasar el tiempo y simplemente nos convertimos en espectadores de como las ideas, sueños y proyectos de los demás se van concretando. Pensamos, yo también tengo muchas ideas, pero no tengo tiempo. Yo también tengo una lista de propósitos pero en cuanto salga de este trabajo las iré cumpliendo. En cuanto tenga el dinero suficiente me dedicaré a lo que realmente me gusta y así la vida se nos va. ¿Crees que hoy es un buen día para cambiar de dinámica?

Con enfoque y determinación

Era un domingo en la mañana, tenía que correr 20 kilómetros y el terreno era variado, empezamos en un plano, luego un par de bajadas y finalmente 5 kilómetros de subida. Las cuestas son los tramos más complicados para muchos corredores, porque se requiere de muchos factores para superarlas. Primero, una cuesta necesita concentración, canalizar energía en los brazos y piernas, relajación, técnica pero sobre todo: determinación. Menciono esto porque el enfoque y la determinación son factores importantes cuando queremos concretar ideas, desarrollar proyectos y cumplir con nuestros objetivos.

Con el tiempo nuestra mente se satura, resulta curioso como nuestro cansancio al final del día no es físico, resulta mental y por lo tanto te olvidas de cualquier actividad física. Pero, quiero compartir contigo algunos tips que te ayudarán a despejar la mente:

• Correr: Es mi favorito, sólo necesitas un par de tenis, ropa cómoda y la determinación para desconectarte de todo por 30 minutos, 40 o 1 hora. Mientras corres tu mente se relaja, tu corazón trabaja, tus músculos se activan y segregas substancias naturales como la endorfina que te produce felicidad.
• Nadar: Recomendable para las personas con sobrepeso, que tienen lesiones o dolores en las articulaciones. Es un ejercicio muy noble y de cero impacto, puedes empezar con 100mts, luego 300mts y así hasta dedicarle 1 hora al día. Con la natación mejoras tu circulación, tienes más aire, mueves todos los músculos de tu cuerpo y te llenas de energía.
• Yoga: Quizás has escuchado muchas veces sobre las bondades del Yoga, pero aunque parece un ejercicio fácil de hacer y en el que sólo debes respirar. El reto, precisamente se encuentra en cómo logras despejar la mente para respirar adecuadamente, tu concentración se incrementa, tu capacidad de sentir tu entorno y oxigenas tu cuerpo de una forma sorprendente.

Con esfuerzo y automotivación

La vida esta llena de obstáculos, dificultades y limitaciones. Pero, también está llena de soluciones, apoyo y oportunidades que llegan a uno de diferentes formas. La educación recibida en la escuela, los valores inculcados en casa y el entorno en el que nos desarrollamos, pueden ser factores a favor o en contra de nuestra capacidad de automotivación y determinación. Lo mejor es ver primero hacia dentro, escudriñar nuestras limitaciones y defectos; pero también evaluar nuestras virtudes y características que nos permiten enfrentar el día a día.

Luego de despejar la mente, la pregunta es ¿cómo concreto mis ideas? considero que lo más importante para ello es establecer prioridades, buscar un esquema, pedir ayuda si es necesario, utilizar métodos o herramientas que nos permitan no perder el enfoque.

• Técnica para concretar: Empecemos hablando de técnicas que te permiten optimizar el tiempo, evaluar cuánto tiempo inviertes en tus sueños, las prioridades y se pone a prueba tu disciplina.
• Metas a plazos: Define tus metas a corto, mediano y largo plazo. Incluso toma un calendario, asigna fechas y tiempo de desarrollo de cada meta. Al final, procura evaluar tus resultados y los factores que no te permitieron cumplir con lo propuesto para volverlo a intentar.
• Crea nuevos hábitos: Como sabrás son todas aquellas acciones que realizamos de forma automática, porque la hemos realizado por tanto tiempo que están instaladas en nuestro disco duro. Pero, tenemos buenos y malos hábitos por ello, trabajemos en crear nuevos que aún no están incorporados en nosotros.

Hace unos días un amigo en Twitter me pidió que escribiera sobre este tema, precisamente porque me expresaba su dificultad en concretar proyectos, ideas o simples acciones de beneficio para su vida. Espero que estas ideas y referencias a otros artículos en donde reflexiono más sobre temas similares a este sirvan de apoyo y los motiven a saber que no están solos en este proceso de la superación personal, hacer sus sueños realidad y los fracasos en el intento. Feliz fin de semana. Enjoy!

Stephanie Falla Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Entrando de nuevo en el tema, en este capítulo nos concentraremos en las herramientas básicas que provee Symfony2 para manipular y detectar peticiones AJAX, las cuales son completamente transparentes para el cliente web (o framework que utilices), de esta forma podrás implementar AJAX de la forma que quieras y con el Framework JS que desees.

Detectando peticiones XmlHttpRequest desde el controlador

La clase Request contiene un función para verificar si la petición HTTP fue enviada por AJAX, es decir por medio del XmlHttpRequest:

// retorna true o false
$this->getRequest()->isXmlHttpRequest();

¡Así de simple!, con ello puedes comprobar de forma efectiva desde tus controladores si la petición fue enviada por AJAX, lo que te permite, entre otras cosas, renderizar una plantilla específica, crear un objeto Response y controlar una salida personalizada como por ejemplo un JSON o XML.

Detectando peticiones AJAX desde la Vista

Controlar AJAX desde el controlador es muy efectivo, pero a veces por la estructura interna de nuestras plantillas (las que usas como layout y las que heredan un layout con la estructura HTML) puede resultar tedioso modificar cada controlador para devolver una plantilla específica, y ¿si dicha plantilla extiende un layout HTML (<html>, <head> y <body>)?: sabemos muy bien que en el caso de AJAX solo necesitamos el fragmento HTML específico, no un árbol HTML completo, por suerte en TWIG podremos hacer esto:

{% extends app.request.isXmlHttpRequest ? "MDWDemoBundle::layout_ajax.html.twig" : "::base.html.twig" %}

De esta forma Twig nos permite comprobar si la petición es AJAX y de este modo tener un layout específico para cada situación.

En el caso de plantillas con PHP, simplemente podemos acceder al objeto Request gracias al contenedor de Inyección de Dependencias (DI) en nuestras vistas:

$this->container->get('request')->isXmlHttpRequest()

Note que se hace una llamada a $this->container esto motivado a que en las plantillas $this->get() intentará cargar los Helpers, con ello especificamos que queremos cargar explícitamente un servicio, en nuestro caso el “Request”.

Esto es todo lo básico que necesitas conocer para implementar AJAX con Symfony 2. ¡Fue muy simple, corto y rápido!, ¿lo querías más difícil? Simplicidad: ése es el objetivo, con esto puedes integrar perfectamente cualquier código JS AJAX, frameworks como jQuery, MooTools, Prototype, ExtJS, Dojo, YUI, etc.

Maycol Alvarez para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Antes de iniciar con la explicación de como funciona Django, dale un vistazo a este vídeo:

Ahora que ya entiendes el contexto, empezamos!

MTV y Django

Se podría clasificar a Django como parte de la tercera generación del desarrollo web:

Generaciones del desarrollo web

Sin embargo más alla de las clasificaciones que podrían existir, está el entender como funciona realmente, al entenderlo se puede llegar a dominarlo.

Al principio del curso de Django, les dije que era un framework MTV (una modificación de MVC, nada que ver con música), esto se debe a que los desarrolladores no tuvieron la intención de seguir algún patron de desarrollo, sino hacer el framework lo más funcional posible.

Para empezar a entender MTV debemos fijarnos en la analogía con MVC.

• El modelo en Django sigue siendo modelo
• La vista en Django se llama Plantilla (Template)
• El controlador en Django se llama Vista

Una imagen nos hará entender mejor esta relación:

Funcionamiento del MTV de Django

Veamos que hace cada uno de ellos con un poco más de detalle y algunos conceptos adicionales.

El modelo

El modelo define los datos almacenados, se encuentra en forma de clases de Python, cada tipo de dato que debe ser almacenado se encuentra en una variable con ciertos parámetros, posee métodos también. Todo esto permite indicar y controlar el comportamiento de los datos.

La vista

La vista se presenta en forma de funciones en Python, su propósito es determinar que datos serán visualizados, entre otras cosas más que iremos viendo conforme avanzamos con el curso. El ORM de Django permite escribir código Python en lugar de SQL para hacer las consultas que necesita la vista. La vista también se encarga de tareas conocidas como el envío de correo electrónico, la autenticación con servicios externos y la validación de datos a través de formularios. Lo mas importante a entender con respecto a la vista es que no tiene nada que ver con el estilo de presentación de los datos, sólo se encarga de los datos, la presentación es tarea de la plantilla.

La plantilla

La plantilla es básicamente una página HTML con algunas etiquetas extras propias de Django, en si no solamente crea contenido en HTML (también XML, CSS, Javascript, CSV, etc).

Por ahora nos enfocaremos a lo básico el HTML. La plantilla recibe los datos de la vista y luego los organiza para la presentación al navegador web. Las etiquetas que Django usa para las plantillas permiten que sea flexible para los diseñadores del frontend, incluso tiene estructuras de datos como if, por por si es necesaria una presentación lógica de los datos, estas estructuras son límitadas para evitar un desorden poniendo cualquier tipo de código Python.

Esto permite que la lógica del sistema siga permaneciendo en la vista.

La configuración de las rutas

Django posee un mapeo de URLs que permite controlar el despliegue de las vistas, esta configuración es conocida como URLConf. El trabajo del URLConf es leer la URL que el usuario solicitó, encontrar la vista apropiada para la solicitud y pasar cualquier variable que la vista necesite para completar su trabajo. El URLConf esta construido con expresiones regulares en Python y sigue la filosofia de Python: Explicito es mejor que implícito. Este URLConf permite que las rutas que maneje Django seán agradables y entendibles para el usuario.

Si consideramos al URLConf en el esquema anterior tendríamos este resultado más completo.

Funcionamiento del MTV de Django y su URLConf

Los archivos predeterminados

Otra parte importante es entender el propósito de los archivos que se crean de manera predeterminada, estos son:

Archivos del proyecto

• __init__.py: Este es un archivo vacío que le dice a Python que debe considerar este directorio como un paquete de Python. Si se desea saber más, se puede consultar la documentación sobre los paquetes.
• manage.py: Este archivo contiene una porción de código que permite interactuar con el proyecto de Django de muchas formas. Si se desea mayor detalle se encuentra la documentación oficial con respecto a manage.py.
• settings.py: Este archivo contiene todas las configuraciones para el proyecto, la documentación al respecto puede darnos mas detalles de la configuración de un proyecto en Django.
• urls.py: Contiene las rutas que están disponibles en el proyecto, manejado por URLConf, los detalles completos como siempre en la documentación oficial nos da mas detalles sobre las urls y Django.

Archivos de la aplicación

• __init__.py: La misma descripción anterior (líneas arriba).
• models.py: En este archivo se declaran las clases del modelo.
• views.py: En este archivo se declaran las funciones de la vista.
• test.py: En este archivo se declaran las pruebas necesarias para la aplicación, para mayor detalle sobre las pruebas y Django se puede consultar la documentación del proyecto.

Una vez que tenemos claro el funcionamiento básico de Django, desarrollemos un ejemplo dentro del proyecto que iniciamos la semana pasada, para experimentar por nuestra cuenta.

Modelo, Vista y Plantilla en 15 minutos

Antes de continuar, deben entender que esto solamente es un pequeño ejemplo, el modelo, vista y plantillas serán desarrolladas a detalle en las próximas semanas. Si existen dudas del porque de las instrucciones, estas serán resueltas a detalle en los siguientes capítulos. Si eres muy impaciente siempre tienes a disposición la documentación oficial del proyecto.

Nuestro proyecto debe tener una estructura similar a esta:

Árbol de ficheros de un proyecto en Django

Tendremos que manejar para este proyecto 6 archivos:

• models.py (ya existe dentro de la carpeta principal).
• views.py (ya existe dentro de la carpeta principal).
• admin.py (aún no existe, pero estará dentro de la carpeta principal).
• urls.py (ya existe dentro de la carpeta recetario).
• settings.py (ya existe dentro de la carpeta recetario).
• lista_bebidas.html (aún no existe, estará dentro de una carpeta en la carpeta recetario).

models.py

Al principio models.py luce asi:

models.py predeterminado

Usamos nuestro editor de texto favorito para editar models.py y redactamos lo siguiente:

from django.db import models

class Bebida(models.Model):
	nombre = models.CharField(max_length=50)
	ingredientes = models.TextField()
	preparacion = models.TextField()

	def __unicode__(self):
		return self.nombre

views.py

views.py luce así al principio:

views.py predeterminado

Igualmente con nuestro editor favorito abrimos views.py y lo dejamos de la siguiente forma:

from principal.models import Bebida
from django.shortcuts import render_to_response

def lista_bebidas(request):
	bebidas = Bebida.objects.all()
	return render_to_response('lista_bebidas.html',{'lista':bebidas})

admin.py

Este archivo no existe, así que lo creamos manualmente dentro de nuestro directorio de la aplicación, en este caso dentro del directorio principal. Lo debemos dejar de esta manera:

from principal.models import Bebida
from django.contrib import admin

admin.site.register(Bebida)

urls.py

Este archivo ya existe, se encuentra dentro del directorio recetario, así que lo único que debemos hacer es modificarlo para dejarlo de la siguiente manera:

from django.conf.urls import patterns, include, url
from django.contrib import admin

admin.autodiscover()

urlpatterns = patterns('',
    url(r'^$','principal.views.lista_bebidas'),
    url(r'^admin/doc/', include('django.contrib.admindocs.urls')),
    url(r'^admin/', include(admin.site.urls)),
)

settings.py

Este archivo lo modificamos la semana pasada, se encuentra dentro de recetario. Debemos buscar la directiva TEMPLATE_DIRS (Debe encontrarse en la línea 113 aproximadamente). Debemos dejar esta sección de esta forma:

TEMPLATE_DIRS = (
    os.path.join(RUTA_PROYECTO,'plantillas'),
)

En esta sección le estamos diciendo que debe buscar las plantillas dentro de la carpeta del proyecto, en una carpeta llamada plantillas, como esta carpeta aún no existe debemos crearla manualmente dentro de recetario.

lista_bebidas.html

Este archivo no existe, lo crearemos manualmente dentro de la carpeta plantillas (si, esa que acabas de crear dentro de recetario).

Debes finalizar con una estructura similar a esta:

Árbol de ficheros del proyecto recetario

Una vez creado le ponemos la etiquetación HTML que nos permita visualizar la lista de bebidas. Podría quedarse de esta manera:

<!DOCTYPE html>
<html lang='es'>
  <head>
	<title>Lista de bebidas de ejemplo</title>
	<meta charset='utf-8'>
  </head>
  <body>
    <h1>Recetario de Bebidas</h1>
	{% for elemento in lista %}
	<ul>
	  <li><strong>{{elemento.nombre}}</strong></li>
	  <li>{{elemento.ingredientes}}</li>
	  <li>{{elemento.preparacion}}</li>
	</ul>
	{% endfor %}
  </body>
</html>

Poner en funcionamiento todo

Listo, tenemos todo listo para ver funcionando nuestro ejemplo, para ello debemos de sincronizar nuevamente nuestra base de datos, para ello, nos ubicamos en la carpeta principal del proyecto (aquella donde se encuentra el archivo manage.py). Una vez en la carpeta principal, desde una terminal digitamos:

python manage.py syncdb

Esto nos dará el siguiente resultado: (prestar atención a la segunda línea que nos indica la creación de una nueva tabla):

Creación de tabla principal_bebidas

Una vez realizado esto, lanzamos nuestro servidor de desarrollo:

python manage.py runserver

Nos ubicamos en http://127.0.0.1:8000/admin, ingresamos con nuestros datos configurados en la primera vez que sincronizamos la base de datos (si no recuerdas los datos que pusiste, puedes borrar el archivo recetario.db y volver a digitar: python manage.py syncdb para resincronizar).

Una vez dentro de la interfaz administrativa veremos: (notar que aparece una opción Bebidas).

Interfaz administrativa de Django + Bebidas

Podemos seguir intuitivamente la interfaz e ingresar datos:

Interfaz inicial de bebidas

Formulario para ingreso de datos

Ingreso de contenido

Lista de elementos ingresados

Una vez guardados podemos ir a http://127.0.0.1:8000/ y veremos lo que acabamos de ingresar. De esta manera ya tienes una interfaz rápida de ingreso y visualización de datos.

Ejemplo de plantilla con Django

Hay muchos puntos que en este capítulo he tenido que tocar superficialmente, esto no debe preocuparte, porque en los siguientes capítulos desarrollaré a detalle esos puntos, deseo recordarte que el objetivo de este pequeño ejemplo, es disfrutar la experiencia de la velocidad de Django, para el desarrollo de aplicaciones.

Si desean ver los archivos oficiales del proyecto, no olviden que pueden acceder al repositorio del mismo en github. Los datos de acceso para la interfaz administrativa del ejemplo del repositorio son los siguientes:

• usuario:sergio
• clave:maestros

La próxima semana tendremos el capítulo dedicado a El Modelo. Muchas gracias por sus comentarios en el capítulo anterior, eso enriquece mucho más cada capítulo.

Sergio Infante Montero para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Existen muchos factores que nos hacen pensar de esa manera, principalmente en Latinoamérica en donde nuestros países son tan peligrosos, no existe cultura de respeto, carecemos de oportunidades y en el momento menos esperado alguien se aprovecha de nosotros ¿cierto?. Yo amo mi país, pero, vivimos a la defensiva, no confiamos en la gente, creemos en la estafa, en un abrir y cerrar de ojos nos despojan de lo que es nuestro. En un contexto como este ¿cómo no vamos a pensar de esta manera? creo que es justificable y necesitamos el escepticismo como arma de defensa.

Canalizar el escepticismo hacia las oportunidades

Sin embargo, porque siempre debe existir una manera diferente de ver las cosas, podemos aprovechar todas esas alertas que tenemos y canalizarlas de forma positiva. Si somos tan hábiles para saber cuando alguien nos “miente o nos quiere ver la cara” por qué no utilizamos ese sentido agudo para detectar personas con talento y capaces de formar parte de nuestro proyecto. Por qué, si somos tan capaces de elevar la voz para denunciar un abuso, un robo o asalto. No utilizamos ese valor para felicitar a otros que con esfuerzo están logrando proyectos interesantes y aprendemos de ellos.

En este medio, compartir tus ideas no es un riesgo de perdida, al contrario es una oportunidad para que más personas con tus mismos intereses te descubran y puedan construir algo en conjunto. Tenemos muchas herramientas de comunicación, el compartir y aprender de alguien extranjero, ya no es un lujo que sólo tienen quienes salen del país a cursar un posgrado o de quienes tienen suficiente dinero para pagar estudios fuera del país. Los medios sociales y las herramientas de comunicación nos permiten armar equipos múltidisciplinarios entorno al Interne sin importar el espacio geográfico.

Comparte tus ideas y proyectos

Debemos aprender a ser proactivos, independientes de los recursos, libres y seguros de las cosas que deseamos alcanzar. Nos decimos freelancer, emprendedores, trabajadores independientes, pero seguimos dependiendo de que la oportunidad, las personas indicadas y el momento preciso llame a nuestra puerta. Cuando en realidad todo eso que buscamos está allá, afuera, en Internet, los eventos, en la calle, la universidad, las redes sociales y hasta en este espacio. ¿Entonces, por qué nuestra idea se sigue llenando de polvo? ¿qué necesitamos? ¿cómo empezar?

No existen fórmulas para lograrlo, pero algo sí te aseguro, existen muchos caminos y muchas oportunidades para hacerlo. Pero, no llegarán a tí, tu debes buscar, trabajar y (des)aprender de las experiencias que no te han permitido lograrlo hasta el momento. Hace una semanas en mejorando.la con @freddier y @cvander hablamos sobre proyectos de financiamiento colectivo, en especial hablamos de Crowdfunding con Kickstarter. Además, hablamos de proyectos similares como:

• Idea.me: Ayuda para creadores latinos para realiar sus proyectos través del financiamiento colectivo.
• Lanzanos.com: Iniciativa española de Público.es donde puedes enviar tus proyectos y obtener el finamiento que necesitas.
• Goteo.org: Red social para cofinanciar y colaborar con proyectos creativos.
• Kickstarter.com: Proyecto en inglés que permite el financiamiento colectivo para proyectos.

Existen muchas formas de lograr que tu proyecto sea conocido, empieza leyendo blogs sobre el tema, Guías de emprendimiento, participa en comunidades, procura ir a eventos sobre temáticas similares. Invierte, participa y cree en otros proyectos latinos como el tuyo y construye ese buen karma. Pero sobre todo, no tengas temor de hablar sobre tu idea porque sólo será una limitante en la búsqueda de llevarla a cabo con éxito. Feliz fin de semana. Enjoy!

Stephanie Falla Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Validación de datos

Como ya hemos visto cada tabla de nuestra base de datos es representada por medio de un Entity en el que usamos annotations para definir los metadatos. Para usar estos annotations importamos el paquete “use Doctrine\ORM\Mapping as ORM;” arriba del archivo y usamos los mismos por medio del alias ORM de esta manera “@ORM\Id”.

Para la validación de los datos importaremos otro namespace: “use Symfony\Component\Validator\Constraints as Assert;” y por medio del alias Assert, utilizando annotations definiremos los validadores para los campos que queramos. El listado completo de validadores o también llamados constraints los puedes ver en la documentación oficial.

Algo que resulta muy importante entender es que la definición de los metadatos que escribimos usando el alias @ORM no tiene el mismo propósito que cuando usamos el @Assert. Por ejemplo, en el caso de nuestro Entity Article, hemos definido que la propiedad (campo/columna) $title no permite nulos. Esto lo hicimos porque dejamos su mapeo como @ORM\Column(name=”title”, type=”string”, length=255) donde por defecto es not null pero esto no implica la validación de los datos ya que lo que acabamos de escribir es que para la creación de la tabla se debe tener en cuenta que no es nulo y esto sirve para generar correctamente el CREATE TABLE necesario.

Para asegurarnos de que no sea nulo a la hora de ingresar los datos debemos usar el @Assert\NotNull() cuyo objetivo es realmente decirle al validador de datos que efectivamente al intentar grabar datos por medio del entity este debe ser validado como que no permite valores nulos.

Estos annotations tienen la misma forma que los anteriores. Son llamadas a métodos que pueden recibir parámetros opcionales. Por ejemplo, si ponemos:

/**
* @var string $title
*
* @ORM\Column(name="title", type="string", length=255)
* @Assert\NotNull()
*/
private $title;

estamos diciendo que la propiedad title no debe permitir valores nulos y al momento de validarlos saldrá una mensaje diciendo eso en ingles, si queremos cambiar el mensaje por defecto lo hacemos agregando el argumento a la invocación de esta manera:

/**
 * @var string $title
 *
 * @ORM\Column(name="title", type="string", length=255)
 * @Assert\NotNull(message="Debe escribir un titulo")
 */
 private $title;

Si quisiéramos validar que un campo debe ser de tipo email usaremos el annotation @Assert\Email() de esta manera:

/**
 * @Assert\Email(
 *     message = "El mail '{{ value }}' ingresado no tiene el formato correcto.",
 * )
 */
 protected $email;

Haciendo referencia a {{ value }} va a mostrar el valor ingresado como parte del mensaje.

Como último ejemplo, si quisiéramos validar la máxima cantidad de caracteres ingresados, podríamos usar el @Assert\MaxLength():

/**
 * @var string $title
 *
 * @ORM\Column(name="title", type="string", length=255)
 * @Assert\NotNull(message="Debe escribir un titulo")
 * @Assert\MaxLength(255)
 */
 private $title;

Y si quisiéramos además de la máxima cantidad de caracteres, controlar la mínima cantidad simplemente lo agregamos también:

/**
 * @var string $title
 *
 * @ORM\Column(name="title", type="string", length=255)
 * @Assert\NotNull(message="Debe escribir un titulo")
 * @Assert\MaxLength(255)
 * @Assert\MinLength(5)
 */
 private $title;

Con esto ya estamos controlando que mínimamente debemos escribir 5 caracteres en el título y como máximo 255.

Como ya había mencionado más arriba, en la documentación oficial tenemos los constraints soportados y si damos click sobre cada uno de ellos veremos como  se utilizan con un ejemplo. Entre ellos encontrarán NotNull, NotBlank, Email, MinLength y MaxLength (para cantidad de caracteres), Max y Min (para valores numéricos), Date, DateTime, Time, Choice (para campos que serán ingresados por medio de un combo de valores por ejemplo).

Al escribir los Asserts en realidad estamos configurando las validaciones que queremos tener pero para validar los datos debemos invocar al validador. Para esto usemos como base el ejemplo que teníamos para la inserción de artículos del capítulo anterior:

public function crearAction()
{
    $articulo = new Articles();
    $articulo->setTitle('Articulo de ejemplo 1');
    $articulo->setAuthor('John Doe');
    $articulo->setContent('Contenido');
    $articulo->setTags('ejemplo');
    $articulo->setCreated(new \DateTime());
    $articulo->setUpdated(new \DateTime());
    $articulo->setSlug('articulo-de-ejemplo-1');
    $articulo->setCategory('ejemplo');

    $em = $this->getDoctrine()->getEntityManager();
    $em->persist($articulo);
    $em->flush();

    return $this->render('MDWDemoBundle:Articulos:articulo.html.twig', array('articulo' => $articulo));
 }

En código anterior, sin validar nada y pasando por alto los constraints de nuestro Entity intenta grabar los datos y si por ejemplo no cargamos un dato obligatorio como el título, el error devuelto será el que la misma base de datos valida ya que la columna fue creada como not null pero lo que queremos es poder obtener la validación en la aplicación, antes que llegue el insert a la base de datos, y esto lo haremos por medio del validador agregando el siguiente código antes de la invocación al EntityManager:

$errores = $this->get('validator')->validate($articulo);

Por medio del objeto $this->get(‘validator’) le decimos que valide la entidad $articulo, quién ya sabe como validarse por si misma ya que los annotations están dentro de la misma. Este método validate() nos devolverá un array de errores que podemos iterar y obtenerlos por medio del método getMessage():

public function crearAction()
{
    $articulo = new Articles();
    //-- No cargamos el dato para title
    $articulo->setAuthor('John Doe');
    $articulo->setContent('Contenido');
    $articulo->setTags('ejemplo');
    $articulo->setCreated(new \DateTime());
    $articulo->setUpdated(new \DateTime());
    $articulo->setSlug('articulo-de-ejemplo-1');
    $articulo->setCategory('ejemplo');

    $errores = $this->get('validator')->validate($articulo);

    if(!empty($errores))
    {
        foreach($errores as $error)
        echo $error->getMessage();

        return new Response();
    }

    $em = $this->getDoctrine()->getEntityManager();
    $em->persist($articulo);
    $em->flush();

    return $this->render('MDWDemoBundle:Articulos:articulo.html.twig', array('articulo' => $articulo));
 }

En el código de arriba hemos borrado la línea del setTitle(). Esto nos mostrará en pantalla el mensaje “Debe escribir un titulo” y si tenemos más errores los mensajes por cada error.

Ahora bien, realmente no tiene mucho sentido mostrar de esta manera los mensajes de errores ya que finalmente ni siquiera cargamos los datos a mano como lo estamos haciendo, sino que son ingresados por un formulario y es aquí donde pasamos al siguiente tema, la creación de formularios.

Creación de Formularios

La posibilidad de crear formularios es uno de los temas que más me gusta de Symfony ya que los mismos no se escriben en HTML sino que son programados como objetos y el mismo framework se encarga de hacer render del HTML necesario y asegurándonos que serán escritos de la mejor manera posible incluso utilizando las validaciones de HTML5.

Un formulario siempre debería ser representado por un objeto que se lo conoce como Type. Este objeto hace referencia a otro que puede ser un Entity (del que ya hablamos en los capítulos anteriores) o un POPO (Plain Old PHP Object).

Un objeto Type se debe tomar como la definición del formulario. Este objeto recibirá cual es el Entity o POPO en el cual se almacenan los datos cargados en el formulario. Podríamos tener más de un Type para un mismo objeto ya que dependiendo de ciertos perfiles por ejemplo, podríamos querer mostrar algunos campos u otros dependiendo de que el usuario sea operador normal o administrador.

Definición de nuestro formulario

Para nuestro ejemplo tomaremos en cuenta el Entity Article que venimos usando y crearemos un objeto Type para representar a este formulario. Los formularios se deben crear dentro de nuestro Bundle en una carpeta Form por lo que crearemos el archivo ArticleType dentro de nuestra carpeta src/MDW/DemoBundle/Form:

<?php
namespace MDW\DemoBundle\Form;
use Symfony\Component\Form\AbstractType;
use Symfony\Component\Form\FormBuilder;
class ArticleType extends AbstractType
{
    public function buildForm(FormBuilder $builder, array $options)
    {
        $builder->add('title')
                ->add('author')
                ->add('created');
    }
    public function getName()
    {
        return 'article_form';
    }
}

Como podemos ver en el ejemplo, el nombre de la clase esta formado por un nombre que yo he elegido concatenado con el sufijo Type y debe heredar de AbstractType para contener las funcionalidades base.

En el método buildForm(), por medio del $builder, que se recibe como argumento, agregamos los campos que vamos a usar. Estos campos son los nombres de los campos que tendrá el formulario y deben coincidir con las propiedades de nuestro Entity Article aunque todavía no hemos dicho que el formulario representará a Article ya que eso lo hacemos en la invocación desde el controller. El argumento options nos servirá para crear el formulario con otras opciones de personalización.

El método getName() deberá retornar el identificador de nuestro formulario y este String puede tomar el nombre que queramos siempre y cuando sea único. Tenemos que tener en cuenta que este nombre será usado para los atributos “name” de los componentes de formularios. Por ejemplo vemos que tenemos un componente llamado “title” que hemos agregado en el método buildForm() por lo que la etiqueta creada será:

<input type="text" name="article_form[title]" />

Hay que notar que esta es la sintaxis para cargar datos en un array (usando los corchetes) por lo que “article_form” será simplemente un array con una clave asociativa “title” que contendrá el valor ingresado por el usuario. Esta sintaxis nos permite tener en un array todos los datos del formulario al hacer el submit.

Con esto lo que hemos hecho es crear la representación básica de nuestro formulario, diciéndole cual es el identificador del formulario y los campos que deberá contener.

Invocación y Visualización del formulario

Para poder mostrar el formulario HTML en nuestra página debemos invocar a nuestra clase ArticleType desde nuestro controlador, o más específicamente desde el action que llama a nuestra página, para esto vamos a crear un action nuevo dentro de nuestro ArticulosController al que vamos a llamar newAction.

Primeramente creamos nuestra ruta en el archivo routing.yml

articulo_new:
 pattern: /articulo/new
 defaults: { _controller: MDWDemoBundle:Articulos:new }

Una vez creada nuestra ruta iremos a crear nuestro newAction en src\MDW\DemoBundle\Controller\ArticulosController.php (MDWDemoBundle:Articulos:new). Para esto agregamos el siguiente código:

//--  Al estar utilizando la clase ArticleType dentro de nuestro método no debemos olvidar importar el namespace al principio del archivo
use MDW\DemoBundle\Form\ArticleType; 
//-- Agregar este método como uno nuevo
public function newAction()
{
    $articulo = new Articles();
    $form = $this->createForm(new ArticleType(), $articulo);
    return $this->render('MDWDemoBundle:Articulos:new.html.twig', array(
        'form' => $form->createView(),
    ));
}

El código que debe contener nuestro action es muy sencillo. Primeramente creamos un objeto Article y luego, por medio del método $this->createForm() invocamos a nuestro objeto ArticleType pasándole nuestro objeto recién creado $articulo, devolviéndonos un objeto de tipo formuario. Finalmente invocamos a la vista como siempre hacemos y pasamos como parámetro el resultado de ejecutar $form->createView().

Con esto ya seremos capaces de ver el código de nuestra vista  MDWDemoBundle:Articulos:new.html.twig que de acuerdo a este nombre lógico debemos crear el archivo new.html.twig dentro de la carpeta src/MDW/DemoBundle/Resources/views/Articulos/ con el siguiente código:

<form action="{{ path('articulo_new') }}" method="post">
    {{ form_widget(form) }}
    <input type="submit" />
</form>

La creación de la etiqueta formulario la hacemos normalmente así como también el botón de submit. Lo único importante aquí es que el action del form debe apuntar a la misma página por lo que creamos el link por medio de path(‘articulo_new’).

La parte mágica está en {{ form_widget(form) }} donde, por medio de form_widget y Twig, pasamos como argumento la variable que nuestro action nos ha enviado y se imprime en la página el código necesario para nuestro formulario. Es decir que veremos el formulario al ingresar a la dirección:  http://localhost/Symfony/web/app_dev.php/articulo/new

Si miramos el código HTML veremos lo siguiente:

<form action="/Symfony/web/app_dev.php/articulo/new" method="post">
    <div id="article_form">
        <input type="hidden" id="article_form__token" name="article_form[_token]" value="62bc1a503b32de46b8755e9a5f5d8855bc8eb877" />
        <div>
            <label for="article_form_title" class=" required">Title</label>
            <input type="text" id="article_form_title" name="article_form[title]" required="required" maxlength="20" />
        </div>
       <div>
            <label for="article_form_author" class=" required">Author</label>
            <input type="text" id="article_form_author" name="article_form[author]" required="required" maxlength="255" />
       </div>
       <div>
             <label class=" required">Created</label>
             <div id="article_form_created">
                 <select id="article_form_created_year" name="article_form[created][year]" required="required">
                     <option value="2007">2007</option>
                     <option value="2008">2008</option>
                     ...
                 </select>
             </div>
        </div>
    </div>

    <input type="submit" />

</form>

Si miramos el código podemos notar los atributos “name” como los explicamos arriba y también vemos que mágicamente el campo “created” se muestra como un campo para seleccionar una fecha. Esto es debido a que el framework reconoce el tipo de input a mostrar ya que sabe, por medio del objeto Articles, que esa propiedad es una fecha. Esto es tremendamente útil ya que muchas veces podría ya reconocer que type agregarle a las etiquetas input, pero si necesitamos definir por nosotros mismos el atributo type lo hacemos agregando un segundo argumento al momento de agregar el campo al $builder:

public function buildForm(FormBuilder $builder, array $options)
{
    $builder->add('title')
        ->add('author', 'checkbox')
        ->add('created');
}

Mientras que si necesitamos hacer que un campo no sea obligatorio lo hacemos enviando un array como tercer argumento ya que por defecto todos los campos son puestos como requeridos con validaciones HTML5:

public function buildForm(FormBuilder $builder, array $options)
{
    $builder->add('title')
        ->add('author', 'text', array('required' => false))
        ->add('created');
}

Como vemos el formulario HTML es impreso directamente en la página usando el {{ form_widget(form) }} incluyendo divs que nos ayudarán a formatear por medio de CSS y mejorar la estructura de mismo pero en caso de querer crear formularios más complejos en diseño también se cuentan con las siguientes opciones que para no extender mucho este capítulo lo veremos quizá en otra entrega:

• form_errors(form): Renderiza lo errores que se encuentren en el formulario.
• form_rest(form): Renderiza los campos de formulario que no hayan sido agregados manualmente con el form_row.
• form_row(form.field): Renderiza un campo específico dentro de un div.
• form_errors(form.field): Renderiza el error para un campo específico.
• form_label(form.field): Renderiza la etiqueta label para un campo específico.
• form_widget(form.field): Renderiza un campo específico.

Procesamiento del Formulario

Ahora que ya vimos como mostrar el formulario en la página y habiendo dicho el action de un form va al mismo action para ser procesado, entremos en detalle de las modificaciones que tenemos que tener en cuenta en el código original dentro del método newAction().

Lo primero que tenemos que pensar es que si para procesar el formulario llamamos al mismo action, ¿Cómo sabemos cuándo mostrar el formulario y cuándo procesarlo?. La respuesta es bien sencilla, cuando el request fue de tipo GET lo deberíamos de mostrar pero en caso de que se haya dado click en el botón submit se ejecuta un request de tipo POST y por lo tanto se debería procesar. Veamos el código modificado de nuestro newAction():

public function newAction()
{
    //-- Obtenemos el request que contendrá los datos
    $request = $this->getRequest();

    $articulo = new Articles();
    $form = $this->createForm(new ArticleType(), $articulo);

    //-- En caso de que el request haya sido invocado por POST
    //   procesaremos el formulario
    if($request->getMethod() == 'POST')
    {
        //-- Pasamos el request el método bindRequest() del objeto 
        //   formulario el cual obtiene los datos del formulario
        //   y los carga dentro del objeto Article que está contenido
        //   también dentro del objeto Type
        $form->bindRequest($request);

        //-- Con esto nuestro formulario ya es capaz de decirnos si
        //   los dato son válidos o no y en caso de ser así
        if($form->isValid())
        {
            //-- Procesamos los datos que ya están automáticamente
            //   cargados dentro de nuestra variable $articulo, ya sea
            //   grabándolos en la base de datos, enviando un mail, etc

            //-- Finalmente, al finalizar el procesamiento, siempre es
            //   importante realizar una redirección para no tener el
            //   problema de que al intentar actualizar el navegador
            //   nos dice que lo datos se deben volver a reenviar. En
            //   este caso iremos a la página del listado de artículos
            return $this->redirect($this->generateURL('articulos'));
        }
    }
    return $this->render('MDWDemoBundle:Articulos:new.html.twig', array(
        'form' => $form->createView(),
    ));
}

Como vemos en las explicaciones del código casi todo es automáticamente realizado por el objeto ArticleType quién al conocer el request ya nos devuelve el mismo objeto original $articulo que le fue entregado en el createForm(new ArticleType(), $articulo);.

En caso de que los datos no sean válidos y el método isValid() retorne false seguirá el hasta mostrar nuevamente el formulario llamando al método $this->render() y el {{ form_widget(form) }} puesto en nuestra misma vista se encargará de mostrar los errores de validación.

Resumen Final

En este capítulo hemos trabajado muchísimo viendo dos temas sumamente importantes: la validación de los Entities y los formularios.

Para las validaciones hemos hablado sobre los @Asserts, simples anotaciones que realizan validaciones poderosas con poco código y vemos que Symfony2 ya nos provee de la gran mayoría que necesitaremos usar.

Hablando sobre los formularios hemos notado la gran diferencia de diseñar los formularios y programar los formularios por medio de clases. Me gusta decir que en Symfony, el concepto de un formulario NO es simplemente introducción de texto sino introducción de texto VÁLIDO para la aplicación, libre de los problemas que hoy se tienen al crear un formulario a mano y tener que recordar pelear con ataques CSRF, XSS, SQL Injection y cambios en caliente con herramientas como Firebug.

El sub-framework de formularios es uno de los que más me hicieron sentir la diferencia entre usar un framework y no hacerlo y todavía hay muchas otras herramientas que nos permite usar como los formularios embebidos.

En el primer capítulo de esta guía hablamos sobre que uno de los objetivos de Symfony es plantear que cada cosa debe ir en su lugar, respetando el concepto del MVC. Con esto podemos ver que no solo podríamos tener un equipo de desarrollo, con personas expertas en cada área, trabajando con el modelado, otras con los controladores y a los diseñadores en la vista, sino que también podríamos hablar de personas que trabajen netamente en la creación de los formularios de la aplicación.

En el siguiente capítulo hablaremos sobre la integración de Ajax en nuestras aplicaciones hechas con Symfony2.

Juan Ardissone para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Django es un framework hecho en Python, por lo tanto se necesita que hayas previamente instalado Python (2.6 o 2.7) y tengas a la mano tu editor de texto favorito. Si no sabes que editores de texto usar, o como instalar Python lee la primera parte de la Guia Python, con esto es suficiente para empezar a trabajar.

Al estar hecho en Python, sería bueno tener en cuenta la sintaxis y fundamentos de este lenguaje, así que si aún no lo sabes y quieres reforzar tus conocimientos, revisa la guía de Python primero antes de continuar con esta, o da un vistazo a este video de mejorando.la

Obtener Django

Para obtener Django se puede:

• Descargar la versión estable oficial más reciente, desde el sitio oficial de Django y descomprimir el archivo, debe aparecer una carpeta con el nombre de Django seguido del número de la versión bajada. (Para esta guía usaremos la versión 1.4)
• Obtener la versión de desarrollo desde el repositorio de Django, para ello se debe usar Subversión, de esta manera:

  svn co http://code.djangoproject.com/svn/django/trunk/

  Una vez que se ha obtenido Django, es momento de instalarlo.

Python y las variables de entorno en Windows

Los usuarios de Windows deben asegurarse de tener Python dentro de las variables de entorno, esto servirá para poder instalar Django y usarlo fácilmente. Si no sabes como hacerlo, mira el siguiente vídeo:

Instalar Django

Una vez que se descomprime el archivo descargado, debemos acceder a la carpeta desde una terminal o ventana de comandos (en caso de los usuarios de Windows). Suponiendo que la versión que elegimos es la 1.4, se tendría que digitar:

 cd Django-1.4

Ya en la carpeta de instalación de Django, se debe digitar la siguiente instrucción: (Debes de tener permisos de administrador)

 python setup.py install

Si usas Ubuntu GNU/Linux, sería algo así:

sudo python setup.py install

Listo eso es todo, ya tienes Django instalado. Si se desea mayor información de como instalarlo o quizás algunas otras opciones, siempre está la documentación del mismo proyecto para guiarnos. Aquí pueden encontrar la Guía completa de instalación de Django.

Si usas OS X Lion, quizás lo más recomendado sería instalar Django usando pip:
Primero, debemos tener Setup Tools para instalarlo, lo descargamos, lo descomprimimos y dentro del directorio (via el terminal)

 sudo python setup.py install 

Una vez con Setup Tools instalado usamos pip:

 sudo pip install Django 

Primer proyecto

Antes de empezar es bueno aclarar que la versión que vamos a utilizar en esta guía es la más reciente (1.4), y varias cosas han cambiado, la información que podrían encontrar en Internet probablemente se encuentre desactualizada.

Para crear nuestro primer proyecto, abrimos una terminal (o ventana de comandos si asi lo conoces en windows), nos ubicamos en la carpeta en donde queremos crear nuestro proyecto y digitamos:

django-admin.py startproject recetario

Esta instrucción creará dos directorios con el nombre del proyecto (en este caso: recetario) y 5 archivos distribuidos de la siguiente manera:

• manage.py
• recetario
  • __init__.py
  • settings.py
  • urls.py
  • wsgi.py

Para ver que el proyecto está funcionando en la terminal debemos escribir:

python manage.py runserver

Al ejecutar esa instrucción debemos visualizar un resultado como el siguiente:

python manage.py runserver

Abrimos el navegador web la dirección http://127.0.0.1:8000/ y debemos ver lo siguiente:

Django http://127.0.0.1:8000

Ya tenemos nuestro proyecto creado.

En el caso de que nos salga un error porque el puerto asignado esta en uso como la siguiente imagen:

Django en puertos en uso

sólo debemos indicar que puerto usaremos para lanzar el servicio, por ejemplo si se desea usar el puerto 8888 entonces se tendría que digitar:

python manage.py runserver 8888

Usaríamos la dirección http://127.0.0.1:8888/ y tendríamos como resultado lo siguiente:

Django en un puerto 8888

Cada proyecto necesita de aplicaciones donde se puedan gestionar los modelos y las vistas. Un proyecto puede tener muchas aplicaciones:

Primera aplicación

Para crear nuestra primer aplicación, desde la terminal y en la carpeta del proyecto, debemos digitar:

python manage.py startapp principal

Esto creará un directorio y cuatro archivos más, lo que nos dejaría con una estructura de archivos como esta:

• manage.py
• recetario
  • __init__.py
  • settings.py
  • urls.py
  • wsgi.py
• principal
  • __init__.py
  • models.py
  • test.py
  • views.py

El poderoso settings.py

Una parte muy importante del proyecto es el archivo settings.py, este archivo permite configurar la conexión a la base de datos, la zona horaria, el idioma, los directorios principales del proyecto, las aplicaciones del proyecto, entre otras cosas.

Aprender a configurar este archivo permite optimizar el funcionamiento del proyecto, veremos las instrucciones principales a configurar:

Codificación de caracteres

Nuestro idioma esta lleno de caracteres especiales como las tildes y las eñes que son las más comunes, la primera sugerencia para manejar esto eficientemente en django debemos agregar la siguiente línea al archivo settings.py

#encoding:utf-8

Ruta del proyecto

Una configuración importante es configurar la ruta del proyecto, esto permitirá lanzar la aplicación desde cualquier directorio y mover el proyecto a cualquier computador con Django instalado. Para ello debemos escribir las siguientes líneas en el archivo settings.py:

# Identificando la ruta del proyecto
import os
RUTA_PROYECTO = os.path.dirname(os.path.realpath(__file__))

Administradores

Cuando Django tiene la opción de DEBUG=False, las notificaciones de error de código deben ser enviadas vía correo electrónico a los administradores, junto con
los detalles completos del error. Para poner los datos de los administradores debemos buscar la siguiente porción:

ADMINS = (
    # ('Your Name', 'your_email@example.com'),
)

Y modificarla para que quede con los nombres de los administradores en forma de tupla, en mi caso lo dejaré así:

ADMINS = (
    ('Sergio Infante Montero', 'raulsergio9@gmail.com'),
)

Configuración de la base de datos

También podemos configurar la conexión a la base de datos según nuestras necesidades, Django soporta de manera predeterminada la conexión con postgresql, mysql, sqlite3 y oracle. En nuestro proyecto usaremos sqlite3.

Debemos buscar la siguiente sección del archivo:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.', # Add 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'.
        'NAME': '',                      # Or path to database file if using sqlite3.
        'USER': '',                      # Not used with sqlite3.
        'PASSWORD': '',                  # Not used with sqlite3.
        'HOST': '',                      # Set to empty string for localhost. Not used with sqlite3.
        'PORT': '',                      # Set to empty string for default. Not used with sqlite3.
    }
}

Y dejarla de la siguiente manera:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3', # Add 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'.
        'NAME': 'recetario.db',          # Or path to database file if using sqlite3.
        'USER': '',                      # Not used with sqlite3.
        'PASSWORD': '',                  # Not used with sqlite3.
        'HOST': '',                      # Set to empty string for localhost. Not used with sqlite3.
        'PORT': '',                      # Set to empty string for default. Not used with sqlite3.
    }
}

Zona Horaria

Django permite configurar la zona horaria del proyecto, la lista de zonas horarias disponibles se pueden encontrar en la wikipedia. Para configurar debemos buscar lo siguiente:

TIME_ZONE = 'America/Chicago'

Yo lo configurare en la zona horaria de Lima/Perú, así que lo modificare de esta forma:

TIME_ZONE = 'America/Lima'

Configuración del idioma

Django también permite configurar el idioma que usará de manera predeterminada para su funcionamiento, para configurar esto debemos buscar lo siguiente:

LANGUAGE_CODE = 'en-us'

Se puede consultar la lista de idiomas disponibles para adecuarlo a nuestras necesidades, yo lo configurare como español de Perú:

LANGUAGE_CODE = 'es-PE'

Aplicaciones instaladas

Un proyecto en Django necesita de aplicaciones, algunas ya vienen configuradas de manera predeterminada. En nuestro proyecto usaremos la aplicación de administración y su documentación, estas ya vienen construidas, y también nuestra primera aplicación creada líneas arriba, llamada principal. Para habilitar estas aplicaciones debemos buscar la siguiente sección que se encuentra casi al final del archivo settings.py

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    # Uncomment the next line to enable the admin:
    # 'django.contrib.admin',
    # Uncomment the next line to enable admin documentation:
    # 'django.contrib.admindocs',
)

Y modificarlas de la siguiente manera:

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'django.contrib.admin',
    'django.contrib.admindocs',
    'principal',
)

Otras opciones de settings.py

Existen otras configuraciones que iremos modificando durante el desarrollo del curso, como el directorio de plantillas, el contenido estático, los archivos cargados por los usuarios, entre otras. Por ahora con estas instrucciones tenemos lo básico para continuar con nuestro proyecto.

Creación de la base de datos

Hasta el momento no se ha creado la base de datos o las tablas predeterminadas del proyecto, solo se ha configurado los parametros de conexión. Para crear la base de datos, debemos digitar desde la terminal o ventana de comandos, la siguiente instrucción (recordar que debemos estar en la carpeta de proyecto para que todo se realice correctamente):

python manage.py syncdb

Esta instrucción deberá mostrar el siguiente resultado:

python manage.py syncdb

Hay una pregunta que debemos responder, se refiere a la creación de un superusuario (un administrador del proyecto), para lo cual respondemos: yes (en caso de responder negativamente, no podremos usar inmediatamente el administrador predeterminado de Django). Luego de ello completamos la información que nos solicita.

Django creación del super usuario

Al finalizar ya estará creada la base de datos, como en este proyecto se usara sqlite3, debera aparecer un archivo nuevo llamado recetario.db, este contiene las tablas y los datos iniciales del proyecto.

Las direcciones URL del proyecto

Para poder visualizar los cambios que hicimos y la interfaz administrativa de Django, aún falta modificar un archivo mas, este es: urls.py (recordar que este archivo se encuentra dentro del directorio recetario). Este archivo contiene lo siguiente:

from django.conf.urls import patterns, include, url

# Uncomment the next two lines to enable the admin:
# from django.contrib import admin
# admin.autodiscover()

urlpatterns = patterns('',
    # Examples:
    # url(r'^$', 'recetario.views.home', name='home'),
    # url(r'^recetario/', include('recetario.foo.urls')),

    # Uncomment the admin/doc line below to enable admin documentation:
    # url(r'^admin/doc/', include('django.contrib.admindocs.urls')),

    # Uncomment the next line to enable the admin:
    # url(r'^admin/', include(admin.site.urls)),
)

Debemos dejarlo de esta manera:

from django.conf.urls import patterns, include, url
from django.contrib import admin

admin.autodiscover()

urlpatterns = patterns('',
    url(r'^admin/doc/', include('django.contrib.admindocs.urls')),
    url(r'^admin/', include(admin.site.urls)),
)

Ejecución del proyecto

Una vez que tenemos todo listo y configurado, debemos nuevamente iniciar el servidor de desarrollo que tiene el proyecto. Ya hicimos esto al principio, solo debemos digitar desde la terminal nuevamente (dentro del directorio del proyecto):

python manage.py runserver

Lucirá de esta manera:

Django 404 predeterminado

Nos muestra un error 404, luego veremos el por qué. Para ingresar a la interfaz administrativa que ya viene construida con Django, ingresaremos a la dirección: http://127.0.0.1:8000/admin, en donde debemos poner el nombre del superusuario y su respectiva contraseña, creados anteriormente (líneas arriba) con la opción syncdb.

Django admin login

Si todo fue correcto debemos visualizar la interfaz administrativa:

Interfaz administrativa predeterminada de Django

Nuestro primer proyecto ya se encuentra configurado para continuar con la construcción de los modelos. Sin embargo antes de ello debemos entender como funciona Django, ese será nuestro próximo capítulo: Entendiendo como trabaja Django.

Hasta la próxima semana

Sergio Infante Montero para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Quiero compartir con ustedes algunos de los recursos que he encontrado en la web para capacitarme y también compartir los nuevo cursos que hemos diseñado para satisfacer esas necesidades que la comunidad ha expresado. Es fácil criticar al sistema y justificar nuestra carencias por la educación poco vigente, pero considero que ante esa problemática que experimenta Latinoamérica en general, debemos aprovechar mejor las herramientas actuales y disciplinarnos para iniciar un proceso según nuestras necesidades y que nos llene de satisfacción.

Cursos, Guías y Streaming

En línea existen muchas opciones para actualizarnos, pero lo más importante es cómo logramos la disciplina necesaria para aprovechar esos recursos. Además, nuestros proyectos tienen el mismo objetivo de proveer de información y conocimiento, por ello me gustaría que revisen los cursos que tenemos disponibles.

• Plataformas educativas: Existen muchas plataformas diseñadas para ofrecer nuevas alternativas de educación y muchas de ellas utilizan el vídeo como un recurso primario, además de ofrecer alternativas de evaluación y ejercicios.
• Recursos gratuitos: Además, las universidades al rededor del mundo están ofreciendo desde sus sitios conocimiento abierto, recursos y hasta cursos.
• Curso Django: El framework para perfeccionista, un curso diseñado para agilizar el desarrollo, con muchas ventajas y características para un trabajo más simple y eficiente. El curso arranca esta semana y puedes revisar el contenido completo.
• Curso Symfony: El framework PHP orientado a objetos, fue diseñado para optimizar el desarrollo de aplicaciones Web y tienes un curso completo a tu disposición.
• Curso Android: Uno de nuestros cursos más famoso, con más de 100 mil lecturas y puedes descargarlo completo en diversos formatos. Además, puede hacer tus consultas en línea.
• Guías: Desde que arrancamos con nuestra sección de guías, nuestro catálogo sigue creciendo y lo que pretende es proveer de información y conocimiento para que los autodidactas sigan aprendiendo y creando contenido colaborativo a través de sus comentarios y sugerencias. Los invitamos a que descarguen nuestras guías en los hermosos formatos .PDF o los demás formatos.
• Mejorando.la: Finalmente quiero invitarte todos los jueves a que te conectes a mejorando.la el streaming en donde @freddier, @cvander y algunos invitados nos actualizan de las tendencias de la industria, imparten cursos, evaluan proyectos y nos muestran otras opciones de aprendizaje.

Esperamos que estos recursos te sirvan como un primer paso para iniciar el proceso de aprendizaje. Recuerda que en ocasiones sólo depende de nosotros, los buenos hábitos y el aprovechar bien el tiempo para canalizar nuestra energía para mejorar y no para sólo quejarnos de lo que el sistema no nos puede proveer. Feliz fin de semana. Enjoy!

Stephanie Falla Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page