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!

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!

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!

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!

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!

Síguenos en: @maestros | Fan page

De ahora en más cuando nos refiramos a una tabla dentro de Symfony hablaremos de un entity o entidad ya que este último es la forma en que Symfony ve a las tablas es decir objetos. Recordemos que nuestras entidades se encuentran dentro de nuestro Bundle en de carpeta src\MDW\DemoBundle\Entity\ y tenemos mapeadas las tablas “articles” y “comments”.

El acceso a nuestras entidades se hará por medio de un objeto de Doctrine llamado EntityManager que vamos a decir que sería como el administrador de las entidades y quién sabrá como interactuar con ellas. Para obtener este objeto simplemente, dentro de nuestro action lo invocamos de la siguiente manera:

$em = $this->getDoctrine()->getEntityManager();

Con esto ya tenemos la referencia a este objeto dentro de una variable “$em”. Ahora bien, para trabajar con los datos necesitaremos de un repositorio. Este repositorio sería el objeto que nos permite solicitar y actualizar datos y para obtenerlo simplemente usamos el nombre lógico de nuestra entidad de esta manera:

$em->getRepository('MDWDemoBundle:Articles');

Obteniendo Datos

Para obtener datos de las tablas tenemos varios métodos realmente mágicos:

• findAll(): Obtiene todos los registros de la tabla. Retorna un array.
• find(): Obtiene un registro a partir de la clave primaria de la tabla.
• findBy(): Obtiene los registros encontrados pudiendo pasar como argumentos los valores que irían dentro del WHERE. Retorna un array.
• findOneBy(): obtiene un registro pudiendo pasar como argumentos los valores que irían dentro del WHERE.

Veamos unos ejemplos de la utilización de estos métodos:

$em = $this->getDoctrine()->getEntityManager();
//-- Obtenemos todos los artículos de la tabla
$articulos = $em->getRepository('MDWDemoBundle:Articles')->findAll();
//-- Obtenemos el artículo con el id igual a 5
$articulo = $em->getRepository('MDWDemoBundle:Articles')->find(5);
//-- Obtenemos el artículo cuyo slug sea "articulo-1"
$articulos = $em->getRepository('MDWDemoBundle:Articles')->findOneBy(array('slug' => 'articulo-1'));
//-- Obtenemos todos los artículos de autor John Doe que sean de la categoría "Symfony"
$articulos = $em->getRepository('MDWDemoBundle:Articles')->findBy(
	array(
		'author' => 'John Doe',
		'category' => 'Symfony'
	)
);

Caso de ejemplo

Para realizar nuestros ejemplos, crearemos unas páginas para nuestras pruebas. Primeramente como ya vimos en el capítulo 3 tenemos que crear nuestras rutas en el archivo src\MDW\DemoBundle\Resources\config\routing.yml, por lo tanto agreguemos el siguiente código:

articulo_listar:
    pattern:  /articulos/listar
    defaults: { _controller: MDWDemoBundle:Articulos:listar }

articulo_crear:
    pattern:  /articulos/crear
    defaults: { _controller: MDWDemoBundle:Articulos:crear }

articulo_editar:
    pattern:  /articulos/editar/{id}
    defaults: { _controller: MDWDemoBundle:Articulos:editar }

articulo_visualizar:
    pattern:  /articulos/visualizar/{id}
    defaults: { _controller: MDWDemoBundle:Articulos:visualizar }

articulo_borrar:
    pattern:  /articulos/borrar/{id}
    defaults: { _controller: MDWDemoBundle:Articulos:borrar }

Como segundo paso crearemos un nuevo controlador dentro de nuestro Bundle con el nombre ArticulosController.php. El archivo lo crearemos dentro de src\MDW\DemoBundle\Controller y contendrá inicialmente el siguiente código con 5 actions para nuestras pruebas, uno por cada ruta creada anteriormente:

<?php

namespace MDW\DemoBundle\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Symfony\Component\HttpFoundation\Response;
use MDW\DemoBundle\Entity\Articles;

class ArticulosController extends Controller
{
	public function listarAction()
	{

	}

	public function crearAction()
	{

	}

	public function editarAction($id)
	{

	}

	public function borrarAction($id)
	{

	}
}

Ahora crearemos dos plantillas para usarlas como visualización de respuesta de nuestros actions. Los archivos los crearemos en  src\MDW\DemoBundle\Resources\views\Articulos\ con los nombres listar.html.twig y articulo.html.twig.

• listar.html.twig: Conforme un array de artículos crea una tabla para mostrar datos:

<h1>Listado de Articulos</h1>
<table border="1">
    <tr>
        <th>ID</th>
        <th>Titulo</th>
        <th>Fecha de Creacion</th>
    </tr>
    {% for articulo in articulos %}
    <tr>
        <td>{{ articulo.id }}</td>
        <td>{{ articulo.title }}</td>
        <td>{{ articulo.created | date('d-m-Y') }}</td>
    </tr>
    {% endfor %}
</table>

• articulo.html.twig: Conforme a un artículo muestra sus datos:

<h1>Articulo con ID {{ articulo.id }}</h1>
<ul>
    <li>Titulo: {{ articulo.title }}</li>
    <li>Fecha de creacion: {{ articulo.created | date('d-m-Y') }}</li>
</ul>

Ahora ya tenemos nuestro código inicial y así que comencemos a trabajar con los datos.

Manipulando datos

1. Inserción de datos
Primeramente trabajaremos en el método crearAction() de nuestro ArticulosController en donde usaremos la entidad Articles para insertar registros. Para esto es bueno notar que en las primeras lineas de nuestro controlador estamos importando el namespace de la entidad con la palabra reservada “use”.

Crearemos un objeto nuevo de la manera tradicional:

$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');

Usando los setters insertamos los datos y pongamos atención en que no usamos el setId() ya que le dijimos a nuestra entidad que se encargue de generarlo por medio de la anotación @ORM\GeneratedValue(strategy=”AUTO”). Tambień notemos que para asignar las fechas de creación y modificación cargamos un objeto DateTime nuevo agregándole una barra invertida adelante para especificar que es una clase del CORE de php ya que si no la ponemos va a esperar que importemos un namespace tal cual como lo hicimos con la clase Articles.

Una vez que tenemos nuestro objeto creado por medio del EntityManager le diremos que sea insertado con el siguiente código:

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

Con el método persist() le decimos que el objeto pasado por argumento sea guardado para ser insertado y la inserción en sí se realizará cuando ejecutemos el método flush(). Con esta orden Doctrine generará la sentencia INSERT necesaria. Finalmente vamos a invocar a nuestra plantilla a quién le pasaremos el artículo para que muestre sus datos:

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

2. Actualizando datos
La actualización de datos es exactamente igual a la inserción con la diferencia que estamos modificando un objeto Articles ya existente, para este ejemplo crearemos el siguiente código en el método editarAction($id):

$em = $this->getDoctrine()->getEntityManager();

$articulo = $em->getRepository('MDWDemoBundle:Articles')->find($id);

$articulo->setTitle('Articulo de ejemplo 1 - modificado');
$articulo->setUpdated(new \DateTime());

$em->persist($articulo);
$em->flush();

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

El método obtiene el id que llega por GET y por medio del EntityManager obtiene el registro y nos devuelve el objeto al cual, usando los setters asignamos los cambios y de la misma forma que la inserción ejecutamos el persist() y el flush(). Esto creará un update en lugar de un insert ya que doctrine puede identificar perfectamente que el artículo ya existe en la base de datos porque ya fue persistido con anterioridad.

3. Mostrando un listado de artículos
Para obtener todos los artículos de una entidad ya vimos el método findAll() por lo que tendremos el siguiente código dentro del método listarAction() para luego enviar el array de Articles a la vista que se encargará de mostrarlos en una tabla.

$em = $this->getDoctrine()->getEntityManager();

$articulos = $em->getRepository('MDWDemoBundle:Articles')->findAll();

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

4. Eliminar un artículo
Para eliminar un artículo simplemente lo obtenemos e invocamos el método remove() que marcará el artículo para ser borrado hasta que ejecutemos el método flush(). Este código lo pondremos en el método borrarAction()

$em = $this->getDoctrine()->getEntityManager();

$articulo = $em->getRepository('MDWDemoBundle:Articles')->find($id);

$em->remove($articulo);
$em->flush();

return $this->redirect(
    $this->generateUrl('articulo_listar')
);

Una vez que lo borramos, redirigimos al usuario a la ruta “articulo_listar”.

Formas alternativas de obtener datos

1. Extensión de los métodos findBy() y findOneBy()
Los métodos findBy() y findOneBy() tienen otros métodos similares conocidos como findBy*() y findOneBy*() donde el asterísco representa cualquier propiedad de nuestra entidad:

//-- Obtenemos todos los artículos de la categoría 'Symfony'
$articulos = $em->getRepository('MDWDemoBundle:Articles')->findByCategory('Symfony');
//-- Obtenemos el artículo con el slug 'artículo-1'
$articulo = $em->getRepository('MDWDemoBundle:Articles')->findOneBySlug('articulo-1');

2. Utilizando las claves foráneas
Otra de las formas de obtener datos es por medio de las claves foráneas las cuales fueros configuradas en nuestra entidad por medio de los annotatios @ManyToOne, @OneToMany. Una vez que obtemos por ejemplo un artículo podríamos obtener todos sus comentarios de la siguiente manera.

$em = $this->getDoctrine()->getEntityManager();
$articulo = $em->getRepository('MDWDemoBundle:Articles')->findOneBySlug('articulo-de-ejemplo-1');
$comentarios = $articulo->getComments();

foreach($comentarios as $c)
{
    echo $c->getContent();
}

Al utilizar la clave foránea configurada en nuestra entidad invocando al getter getComments(), doctrine se encargará se generar la sentencia SELECT necesaria para obtener todos los comentarios.

3. Generando DQL
Por si las formas de obtener datos que ya vimos nos quedan cortas, cosa que por lo general es así, Doctrine nos permite trabajar con algo muy parecido al SQL estándar al que estamos acostumbrados a trabajar solo que como estamos trabajando con el ORM se llama DQL es decir Doctrine Query Language.

El DQL es realmente muy parecido al SQL con la diferencia que en lugar de hacer queries contra registros de las tablas, los hacemos sobre objetos de tipo Entity, por ejemplo un select bien sencillo:

SELECT * FROM articles

en DQL sería:

select a from MDWDemoBundle:Articles a

donde la “a” es nada más que un simple alias que podemos llamar como queramos. El cambio principal se nota en que en lugar se hacer referencia a la tabla articles estamos haciendo referencia a la entidad MDWDemoBundle:Articles. Con esta sintaxis estamos dejando que doctrine se encargue de la traducción al SQL necesario para el motor de base de datos utilizado y configurado inicialmente.

También es posible pedir solo algunos campos y no un SELECT * poniendo los nombres de las propiedades del objeto usando el alias:

select a.id, a.title, c.author from MDWDemoBundle:Articles a

Para decirle a Doctrine que ejecute este DQL lo hacemos a través del EntityManager de la siguiente manera:

$em = $this->getDoctrine()->getEntityManager();
$dql = "select a from MDWDemoBundle:Articles a";
$query = $em->createQuery($dql);
$articulos = $query->getResult();

Con el código anterior utilizamos el DQL para generar un objeto de Doctrine llamado “Doctrine_Query” representado por $query y luego a este objeto le pedimos que nos devuelva los resultados invocando al getResult() lo que nos devolverá un array de objetos Articles y para acceder a sus datos simplemente utilizamos los getters del objeto. Por ejemplo si quisieramos recorrer el array de articulos y obtener el id lo haríamos así ya que siguen siendo objetos metidos dentro de un array:

foreach($articulos as $articulo)
{
    $id = $articulo->getId();
    $title = $articulo->getTitle();
}

En caso de necesitar pasar filtros para el WHERE, podemos hacerlo usando el método setParameter() del objeto Doctrine_Query de la siguiente manera:

$em = $this->getDoctrine()->getEntityManager();
$dql = "select a from MDWDemoBundle:Articles a where a.author=:author and a.title like :title";
$query = $em->createQuery($dql);
$query->setParameter('author', 'John Doe');
$query->setParameter('title', '%ejemplo 1%');
$articulos = $query->getResult();

Con la utilización del setParameter() ya no nos preocupamos de poner por ejemplo comillas a los filtros que no son numéricos ya que Doctrine ya sabe de que tipo de dato es cada columna por medio de la definición que hicimos de la entidad.

También tenemos por supuesto soporte para unir entidades por medio de la cláusula JOIN por lo que este SQL estándar lo podríamos convertir a DQL de la siguiente manera:

$em = $this->getDoctrine()->getEntityManager();
$dql = "select a.id, a.title, c.author
        from MDWDemoBundle:Comments c
        join c.article a
        where a.author=:author
        and a.title like :title";
$query = $em->createQuery($dql);
$query->setParameter('author', 'John Doe');
$query->setParameter('title', '%ejemplo 1%');
$articulos = $query->getResult();

Hay una diferencia a la hora de obtener los datos. Ya que estamos obteniendo una mezcla de datos de articulos y comentarios, el método getResult() nos devuelve todo ya directamente en un array como siempre estuvimos acostumbrados a trabajar con PDO por lo tanto la estructura del array devuelto sería la siguiente:

Array
(
    [0] => Array
    (
        [id] => 4
        [title] => Articulo de ejemplo 1
        [author] => Autor 1
    )
    [1] => Array
    (
        [id] => 4
        [title] => Articulo de ejemplo 1
        [author] => Autor 2
    )
)

4. Utilizando el Repositorio
En el capítulo anterior cuando nos ocupamos de crear nuestras entidades Articles y Comments con el generador doctrine:entity:create, se nos hizo una pregunta   sobre si queríamos que el generador nos cree un repositorio vacío para la entidad a crear y hemos dicho que sí. Esto hizo que se cree un segundo archivo a parte de la entidad llamado NombreEntidadRepository.php. Para nuestro ejemplo hemos creado el ArticlesRepository.php y el CommentsRepository.php.

Estos archivos se utilizan para organizar sentencias DQL de una entidad en cuestión. Por ejemplo, en lugar de tener todos los códigos de DQL escritos más arriba esparcidos por nuestros Controladores, podríamos ( y deberíamos para mantener el código más ordenado y mantenible)  tener todos las consultas relacionadas con los articulos dentro de nuestro repositorio ArticlesRepository.php. Esto es muy útil ya que desde el primer capítulo hablamos que Symfony intenta mantener todas las cosas en su lugar y es realmente útil.

En este mismo momento nuestro repositorio de artículos se encuentra de la siguiente manera:

<?php
namespace MDW\DemoBundle\Entity;
use Doctrine\ORM\EntityRepository;
/**
 * ArticlesRepository
 *
 * This class was generated by the Doctrine ORM. Add your own custom
 * repository methods below.
 */
class ArticlesRepository extends EntityRepository
{
}

Dentro de esta clase crearemos métodos que serán cada una de nuestras consultas . Fijémonos que la clase hereda de EntityRepository lo cual ya nos da ciertas ventajas por ejemplo que para obtener el EntityManager simplemente tenemos que invocarlo como $this->getEntityManager(). Así que podríamos tener por ejemplo un método para obtener artículos de un autor con un cierto contenido en el título creando el siguiente método:

public function findArticlesByAuthorAndTitle($author, $title)
{
    $em = $this->getEntityManager();

    $dql = "select a.id, a.title, c.author
        from MDWDemoBundle:Comments c
        join c.article a
        where a.author=:author
        and a.title like :title";

    $query = $em->createQuery($dql);
    $query->setParameter('author', $author);
    $query->setParameter('title', '%' . $title . '%');

    $articulos = $query->getResult();

    return $articulos;
}

Una vez que tengamos nuestros métodos en el repositorio lo accedemos de la misma forma que los métodos find() o findAll() ya vistos dentro de nuestros actions en los controladores:

$em = $this->getDoctrine()->getEntityManager();
$articulos = $em->getRepository('MDWDemoBundle:Articles')->findArticlesByAuthorAndTitle('John Doe', 'ejemplo 1');

En cada repositorio podemos tener la cantidad de métodos que necesitemos y hasta podríamos hacer que métodos genéricos que reutilicen otros métodos de la misma clase lo cual, si pensamos en una aplicación que puede llegar a utilizar muchas sentencias SQL lograríamos tener un código mucho más ordenado y por supuesto también tenemos identificado donde pueden ocurrir los errores ya que cada cosa está en su lugar.

Resumen Final

Si pensáramos nuevamente en la arquitectura Model-View-Controller (MVC) estaríamos viendo que la presentación de los datos (View) se encuentran en las plantillas, la programación del modelado de datos y trabajo con los mismos (Model) se encuentran en las Entidades y Repositorios.

Por último nos queda la lógica de la aplicación (Controller) que se mantendrá dentro de los actions programados dentro de cada Controlador. Esto al mirarlo desde un enfoque de arquitectura de software demuestra un proyecto muy ordenado y por sobre todo con facilidades de mantener y escalar a futuro, con un equipo de desarrollo donde cada quién maneja su parte. Algo que siempre suelo decir es que si una página llega a tener más de 20 líneas de código es porque nos estamos olvidando de modularizar y es probable que una de las partes del MVC no se encuentre en el lugar correcto.

En el siguiente capítulo, el último orientado al modelado, hablaremos sobre la validación de los datos que Doctrine nos proporciona y sobre como Symfony nos ayuda a crear objetos de tipo formularios para que los usuarios finales interactuen con la aplicación.

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

Síguenos en: @maestros | Fan page

El crecimiento de Python es cada vez mayor y esto se ha hecho más notorio en los últimos años, con la aparición de herramientas que hacen el trabajo más simple y eficiente con este lenguaje de programación. Una de esas herramientas es Django, el framework hecho en python para perfeccionistas.

Ventajas de Django

Aparte de las ventajas que tiene por ser framework, Django promueve el desarrollo rápido, se construyen aplicaciones en cuestión de días y con el conocimiento suficiente esos días se pueden reducir a horas.

Django impulsa el desarrollo de código limpio al promover buenas prácticas de desarrollo web, sigue el principio DRY (conocido también como Una vez y sólo una).

Django usa una modificación de la arquitectura Modelo-Vista-Controlador (MVC), llamada MTV (Model – Template – View), que sería Modelo-Plantilla-Vista, está forma de trabajar permite que sea pragmático.

Origen de Django

Django nace como un proyecto para publicación de noticias de Lawrence Journal-World, lo interesante de Django es que desde un principio fue construido como una herramienta para resolver problemas reales en un entorno empresarial, fue diseñado para optimizar el tiempo de desarrollo y los requerimientos exigentes de los desarrolladores web.

El nombre de Django es en honor al famoso músico frances Django Reinhardt.

¿Quienes usan Django?

La lista de sitios web alrededor del mundo es enorme, pero es bueno fijarnos en los sitios más populares que usan Django como solución a sus necesidades. Estos son:

• dpaste.com
• The Washington post (en parte)
• Bitbucket.org
• Disqus
• Instagram
• Pinterest
• michaelmoore.com
• theguardian
• lawrence.com
• curse
• The New York Times (represent project)
• Fluendo

Se pueden encontrar mas casos de implementación e incluso varios de ellos con el código fuente en djangosites.

Django en América Latina

En américa latina las experiencias con Django también están presentes, en la mayoria de paises ya se han hecho implementaciones y desarrollo con este estupendo framework. Por ejemplo en el Campus Party de Colombia del 2010 se dio esta presentación:

¿Dónde encontrar mayor información sobre Django?

La mejor fuente de información con respecto a Django es la documentación oficial del proyecto, también existen otras fuentes muy buenas de información, aquí una lista de estos recursos:

• Django en Español: Sitio web de la comunidad española de Django.
• Grupo de Google para usuarios de habla hispana de Django.
• Django Snippets: Sitio donde se comparten Snippets

Curso Django en Maestros del web

En Maestros del Web desarrollaremos un curso para aprender el uso de este potente framework, en el encontrarán recursos, recomendaciones, videos para que puedan usarlos como referencia y lograr cosas geniales en corto tiempo.

Modo de trabajo

Con el contenido del curso desarrollaremos una aplicación sencilla tocando los puntos más importantes. La aplicación será un recetario de comidas y bebidas, el cual se ira construyendo a lo largo de los capítulos, el código será publicado en github.

Lanzamiento de curso en línea

Cada lunes estaremos publicando un capítulo del curso iniciando la próxima semana. Los 10 capítulos a desarrollar en el curso son:

1. Instalación y primera aplicación
2. Entendiendo como trabaja Django
3. El modelo de datos
4. El Shell de Django
5. Las vistas
6. Las plantillas
7. Los formularios
8. Los archivos estáticos
9. Gestión de usuarios
10. Despliegue en el servidor web

Al finalizar la guía estará disponible para descargar en los formatos: .PDF, .epub y disponible en Amazon para el Kindle.

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

Síguenos en: @maestros | Fan page

“Adictos a la comunicación” fue mi primer ebook publicado en @maestros en 2011, el cual cuenta con más de 100 mil descargas. Al ver la reacción a este proyecto, se me ocurrió el desarrollo de una nueva guía pero esta vez enfocada a Freelancers, pero con la idea de responder ¿qué quieres saber los freelancers? ¿qué información necesitan? ¿qué temas les gustaría que se desarrollen en ella?

Guía para Freelancers

Con ese objetivo, lanzo este artículo en donde me gustaría conocer ¿qué información y conocimiento necesitan? en el transcurso de esta serie de Es viernes! me he alimentado de sus ideas, comentarios y sugerencias para seguir desarrollando contenidos. Pero, en esta ocasión me gustaría ser más directa y preguntarles sobre la información que quieren leer en un ebook sobre “Freelancer” precisamente porque a estas alturas, considero que el tiempo es muy valioso y también la interacción, me resulta más dinámico escribir un texto que satisface necesidades a escribir mis percepciones o experiencias individuales.

Creemos que este será un proyecto interesante, en el que junto a mi socio Cvander podemos resolver puntualmente las dudas, brindar sugerencias, investigar y plasmar la información exacta que ustedes necesitan obtener de una Guía para Freelancers. Les agradeceré que en sus comentarios realicen sus propuestas de los temas que les gustaría que desarrollemos. Luego de su retroalimentación, empezaremos a trabajar en ello y esperamos que sea un nuevo ebook de referencia, utilidad y satisfaga sus necesidades.

¿Por qué es importante emprender este tipo de proyectos?

Cuando te has especializado en algún tema, la mejor forma de seguir aprendiendo sobre él y de concretizar tus ideas es cuando lo compartes y produces conocimiento. Escribir no es una tarea sencilla, empezando porque organizar las ideas para que ese conocimiento tenga forma y llegue a otros no siempre se logra. Además, porque siempre habrán críticas sobre lo que haces y no todos estamos dispuestos a exponer públicamente lo que sabemos.

Pero, recuerda que en la actualidad, cuando buscas trabajar con alguien o pides trabajo, lo primero que harás o te pedirán es una prueba de lo que sabes. Por ello, creemos que nuestra mejor carta de presentación ante el mundo son nuestros proyectos, las tecnologías que usamos, la forma en que nos proyectamos en los medios sociales, la opinión que nos atrevemos a emitir en los diversos canales y sobre todo el contenido que producimos.

Entonces, nos encantaría emprender este proyecto de una Guía para Freelancers conociendo las necesidades principales de nuestros lectores, escríbenos sobre los temas que te gustaría encontrar en el proyecto y cada sugerencias será tomada en cuenta para construir contenido de calidad y que satisface tus necesidades de conocimiento. Desde ya, gracias por sus comentarios. Buen fin de semana. Enjoy!

Síguenos en: @maestros | Fan page

Como ya lo habíamos hablado en el capítulo 1, Doctrine es un ORM (Object-Relational Mapping). Cuando hablamos de relaciones en conceptos de base de datos, estamos refiriéndonos a las tablas diciendo entonces que existe una vinculación entra las tablas y objetos. Al usar un ORM mapeamos cada tabla con objetos dentro de nuestras aplicaciones, por ejemplo si tenemos una tabla de personas en la base de datos, tendremos un objeto Persona en la aplicación que conoce cuales son sus campos, tipos de datos, índices, etc. logrando con esto que la aplicación conozca el modelo de los datos desde un punto de vista orientado a objetos, es decir representado con Clases y Objetos.

Doctrine nos permitirá, conociendo nuestras tablas como hablamos anteriormente, crear las sentencias SQL por nosotros ya que toda la información necesaria para crear estos queries se encuentra “mapeada” en código PHP.

Como si esto fuera poco, la mayor de las ventajas de contar con un ORM será que nos permite como desarrolladores, abstraernos de que motor de base de datos estemos usando para el proyecto y nos permitirá, con solo un poco de configuración, cambiar toda nuestra aplicación por ejemplo de una base de datos MySQL a PostgreSQL o a cualquier otra soportada por el framework Doctrine.

Configuración de la base de datos

Para configurar los datos de la conexión del servidor de base de datos se deberán ingresar los valores en el archivo app\config\parameters.ini dentro de las variables ya definidas:

• database_driver = pdo_mysql
• database_host = localhost
• database_port =
• database_name = blog
• database_user = maestros
• database_password = clavesecreta

Estos datos serán usados por Doctrine para conectarse al servidor y trabajar con la base de datos. No hay necesidad de ingresar el puerto si se está usando el que figura por defecto para la base de datos que usemos, para nuestro caso MySQL.

Una vez que ya tenemos configurada nuestra base de datos, podemos usar el comando “console” para decirle a nuestro proyecto que se encargue de crear la base de datos en el servidor ejecutándolo de la siguiente manera:

C:\wamp\www\Symfony>php app\console doctrine:database:create
Created database for connection named <comment>blog</comment>

Esto nos retornará un mensaje diciéndonos, si los permisos estaban correctos, que la base de datos blog fue creada. Podemos revisar ahora nuestra base de datos por medio del phpMyAdmin y veremos que la base de datos ya existe.

El concepto que suele ser muy utilizado en frameworks de este tipo es ir creando la base de datos desde la aplicación, es decir, que la aplicación se encargue de crear la base de datos, las tablas, relaciones, índices y los datos de ejemplo. Este concepto lo iremos ahondando durante estos capítulos.

Creando las tablas y conociendo las Entidades

Como ejemplo usaremos dos tablas para nuestro manual simplemente para ver como trabajar con ellas usando el framework. Crearemos una tabla de Artículos y una de Comentarios para tener como ejemplo el concepto ya bien conocido de un blog.

A continuación tenemos el SQL de las tablas con sus campos:

CREATE TABLE IF NOT EXISTS `articles` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `title` varchar(255) NOT NULL,
  `author` varchar(255) NOT NULL,
  `content` longtext NOT NULL,
  `tags` varchar(255) NOT NULL,
  `created` date NOT NULL,
  `updated` date NOT NULL,
  `slug` varchar(255) NOT NULL,
  `category` varchar(255) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

CREATE TABLE IF NOT EXISTS `comments` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `author` varchar(255) NOT NULL,
  `content` longtext NOT NULL,
  `reply_to` int(11) NOT NULL,
  `article_id` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `IDX_A6E8F47C7294869C` (`article_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

Para crear estas tablas en la base de datos primeramente lo haremos en código PHP para que Doctrine conozca perfectamente las tablas para poder interactuar con ellas. Es aquí donde conocemos el concepto de las Entidades (Entities). Una entidad es la representación “orientada a objetos” de nuestras tablas, es decir que crearemos una clase por cada una de nuestras tablas. Para no tener que escribirlas a mano, Symfony nos provee un generador de Entidades que es invocado con nuestro comando console de la siguiente manera:

C:\wamp\www\Symfony>php app\console doctrine:generate:entity

Al darle enter nos preguntará el nombre que usaremos para nuestra entidad y hay que entender que sigue el siguiente formato: IdentificadorDelBundle:NombreEntidad. Para nuestro caso, y como ya vimos en los capítulos anteriores, nuestro identificador del Bundle es MDWDemoBundle y primero crearemos la entidad para nuestra tabla de artículos por lo tanto escribiremos lo siguiente:

The Entity shortcut name: MDWDemoBundle:Articles

Al darle enter nos preguntará que formato queremos usar para agregar los metadatos que mapearan a la tabla proponiéndonos [annotation]. Aceptaremos la propuesta presionando Enter

Configuration format (yml, xml, php, or annotation) [annotation]:

Luego ya nos empezará a preguntar cuales serán las columnas de nuestra tabla y por cada columna el tipo de dato que arriba nos deja como ejemplo cuales podemos elegir. En caso de que sea un tipo de datos que necesite longitud también nos la pedirá y cuando ya no queramos ingresar columnas simplemente daremos un enter dejando vacío el valor.

Una vez finalizada la carga de los campos, nos preguntará si queremos crear un repositorio vacío a lo que contestaremos SI para luego, como último paso preguntarnos si confirmamos la creación automática de la Entidad a lo que también diremos que SI:

Instead of starting with a blank entity, you can add some fields now.
Note that the primary key will be added automatically (named id).

Available types: array, object, boolean, integer, smallint,
bigint, string, text, datetime, datetimetz, date, time, decimal, float.

New field name (press <return> to stop adding fields): title
Field type [string]:
Field length [255]:

New field name (press <return> to stop adding fields): author
Field type [string]:
Field length [255]:

New field name (press <return> to stop adding fields): content
Field type [string]: text

New field name (press <return> to stop adding fields): tags
Field type [string]:
Field length [255]:

New field name (press <return> to stop adding fields): created
Field type [string]: date

New field name (press <return> to stop adding fields): updated
Field type [string]: date

New field name (press <return> to stop adding fields): slug
Field type [string]:
Field length [255]:

New field name (press <return> to stop adding fields): category
Field type [string]:
Field length [255]:

New field name (press <return> to stop adding fields):

Do you want to generate an empty repository class [no]? yes

Summary before generation

You are going to generate a "MDWDemoBundle:Articles" Doctrine2 entity
using the "annotation" format.

Do you confirm generation [yes]?

Entity generation

Generating the entity code: OK

You can now start using the generated code!

Una vez finalizado el generador, tendremos dos archivos creados dentro de la carpeta src\MDW\DemoBundle\Entity ya que como prefijo de nuestro nombre de Entidad usamos el identificador de nuestro Bundle (MDWDemoBundle). El primer archivo será nuestra entidad Articles.php y el otro será el repositorio de esa entidad ArticlesRepository.php del cual hablaremos en el siguiente capítulo.

Si revisamos el contenido de estos archivos podremos ver que es una Clase con el nombre Articles y que contiene como propiedades los datos que hemos cargado de las columnas de la tabla incluyendo sus métodos getters y setters. También podremos ver que la información que mapea los datos de la tabla se encuentra como parte de bloques de comentarios sobre cada propiedad usando el concepto de Anotaciones, concepto muy conocido en el lenguaje Java. Esta información será utilizada en runtime para conocer datos sobre la entidad. Comentemos algunos más importantes:

• @ORM\Entity: Indica que esta tabla se comportará como una entidad, es decir que mapeará una tabla de la base de datos.
• @ORM\Table: Doctrine usará el nombre de nuestra entidad para crear una tabla en la base de datos con el mismo nombre y esta anotación nos permitirá especificar un nombre diferente si agregamos el parametro name: @ORM\Table(name=”nombre_tabla”).
• @ORM\Column: Indica que esta propiedad mapea una columna de la tabla y como argumentos recibe datos de la misma como por ejemplo el tipo de dato y el largo en el caso de ser string. Doctrine se encargará de crear estas columnas con el tipo de dato correspondiente para cada motor de base de datos
• @ORM\Id: Indica que esta propiedad/columna será la Clave Primaria de la tabla
• @ORM\GeneratedValue: Indica que este campo numérico se irá autoincrementando usando la estrategia que pasemos por parámetro. En este caso AUTO hará que elija la mejor forma según el motor de base de datos que usemos, por ejemplo si usamos MySQL creará un indice autonumérico mientras que si es PostgreSQL usará un dato de tipo SERIAL.

C:\wamp\www\Symfony>php app\console doctrine:generate:entity

  Welcome to the Doctrine2 entity generator

This command helps you generate Doctrine2 entities.

First, you need to give the entity name you want to generate.
You must use the shortcut notation like AcmeBlogBundle:Post.

The Entity shortcut name: MDWDemoBundle:Comments

Determine the format to use for the mapping information.

Configuration format (yml, xml, php, or annotation) [annotation]:

Instead of starting with a blank entity, you can add some fields now.
Note that the primary key will be added automatically (named id).

Available types: array, object, boolean, integer, smallint,
bigint, string, text, datetime, datetimetz, date, time, decimal, float.

New field name (press <return> to stop adding fields): author
Field type [string]:
Field length [255]:

New field name (press <return> to stop adding fields): content
Field type [string]: text

New field name (press <return> to stop adding fields): reply_to
Field type [string]: integer

New field name (press <return> to stop adding fields):

Una vez que tengamos estas 2 entidades creadas podemos probar crear las tablas en la base de datos con el siguiente comando:

C:\wamp\www\Symfony>php app\console doctrine:schema:create

Ahora revisando la base de datos con el phpMyAdmin podremos ver como ambas tablas fueron creadas por nuestro proyecto y nos daremos cuenta como Doctrine, por medio de nuestras Entidades, conoce perfectamente como crearlas.

Modificando la estructura de las tablas

Ahora que ya tenemos nuestras Entidades tenemos que crear la relación que existe entre ellas. Para este caso decimos que un Articulo puede llegar a tener varios comentarios relacionados, mientras que un comentario pertenece a un artículo específico, por lo que en la tabla de comentarios deberíamos agregar una Clave Foránea apuntando a la tabla de artículos. Para esto, agregaremos la siguiente propiedad con sus respectivos getter y setter a nuestra entidad Comment:

    /**
     * @ORM\ManyToOne(targetEntity="Articles", inversedBy="comments")
     * @ORM\JoinColumn(name="article_id", referencedColumnName="id")
     * @return integer
     */
    private $article;
    public function setArticle(\Mdw\BlogBundle\Entity\Articles $article)
    {
        $this->article = $article;
    }

    public function getArticle()
    {
        return $this->article;
    }

Con este código estamos definiendo una relación entre ambas tablas y nuevamente las anotaciones permiten a Doctrine especificar como se define la FK:

• @ORM\ManyToOne: Esta anotación le dice que desde esta tabla de comentarios existe una relación de muchos a uno con la entidad Articles
• @ORM\JoinColumn: Especifica las columnas que se usarán para hacer el join. Localmente se usará una campo article_id y en la tabla de referencia se usará la propiedad id

    /**
     * @ORM\OneToMany(targetEntity="Comments", mappedBy="article")
     */
    private $comments;
    public function __construct()
    {
        $this->comments = new \Doctrine\Common\Collections\ArrayCollection();
    }
    public function addComments(\Mdw\BlogBundle\Entity\Comments $comments)
    {
        $this->comments[] = $comments;
    }

    public function getComments()
    {
        return $this->comments;
    }

Agregando la propiedad $comments estamos creando la referencia a la otra tabla ya que un artículo puede tener varios comentarios usamos la anotación inversa a la que vimos anteriormente @ORM\OneToMany y podremos ver que agregamos un constructor que inicializa la propiedad con un objeto del tipo ArrayCollection, que nos permitirá que un artículo contenga varios comentarios para así poder obtenerlos todos a través del método getComments().

Con estas modificaciones realizadas volvamos a generar nuestras tablas, pero como ya hemos creado ambas tablas, ejecutemos primeramente para borrarlas el siguiente comando:

C:\wamp\www\Symfony>php app\console doctrine:schema:drop --force

Para luego volver a crearlas usando el comando ya conocido:

C:\wamp\www\Symfony>php app\console doctrine:schema:create

La otra manera de actualizar nuestras tablas, en caso de no poder o no querer borrarlas es usando el comando de update donde podemos ver la gran potencia que nos provee Doctrine enviando solo el SQL necesario para actualizar las tablas

C:\wamp\www\Symfony>php app\console doctrine:schema:update --force

C:\wamp\www\Symfony>php app\console doctrine:schema:create --dump-sql
ATTENTION: This operation should not be executed in a production environment.

CREATE TABLE Articles (id INT AUTO_INCREMENT NOT NULL, 
title VARCHAR(255) NOT NULL, author VARCHAR(255) NOT NULL,
content LONGTEXT NOT NULL, tags VARCHAR(255) NOT NULL,
created DATE NOT NULL, updated DATE NOT NULL,
slug VARCHAR(255) NOT NULL, category VARCHAR(255) NOT NULL,
PRIMARY KEY(id)) ENGINE = InnoDB;

CREATE TABLE Comments (id INT AUTO_INCREMENT NOT NULL,
author VARCHAR(255) NOT NULL, content LONGTEXT NOT NULL,
reply_to INT NOT NULL, PRIMARY KEY(id)) ENGINE = InnoDB

C:\wamp\www\Symfony>php app\console doctrine:schema:update --dump-sql

ALTER TABLE comments ADD article_id INT DEFAULT NULL;
ALTER TABLE comments ADD CONSTRAINT FK_A6E8F47C7294869C FOREIGN KEY (article_id)
 REFERENCES Articles(id);
CREATE INDEX IDX_A6E8F47C7294869C ON comments (article_id)

C:\wamp\www\Symfony>php app\console doctrine:schema:drop --dump-sql

ALTER TABLE comments DROP FOREIGN KEY FK_A6E8F47C7294869C;
DROP TABLE articles;
DROP TABLE comments

Resumen Final

Como vemos, el framework Doctrine, al tener los datos de la base de datos y de las tablas, nos proporciona un soporte muy potente para trabajar con ellas y eso que solo hemos visto la parte de creación, borrado y modificación de tablas. En los siguientes capítulos trabajaremos manipulando los datos de las tablas y le proporcionaremos aún más información a nuestras entidades para ayudarnos a validar los datos ingresados en nuestros campos.

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

Síguenos en: @maestros | Fan page

El espacio de trabajo.

Es ese lugar o templo como algunos lo llamamos en el cual descargamos todas las energias y conocimientos para desarrollar nuestras ideas, para algunos es una mesa de madera donde ubicas tu equipo, otros utilizan un comedor, una silla, un sofa, incluso la cama, pero, son estos últimos los espacios adecuados para trabajar.

Antes de definir cual debe ser nuestro espacio de trabajo ideal debemos tener en cuenta lo siguiente:

• Comodidad y ergonomía: una buena posición nos puede ayudar a concentrarnos más y desgastarnos menos físicamente, a veces lo que creemos que es comodidad resulta ser un dolor de espalda u otra parte del cuerpo luego de un buen rato.
• Ruido: busca un lugar donde puedas trabajar sin que el ruido te afecte en la concentración, una buena técnica es ponerte unos auriculares y escuchar música relajante que te ayude a escribir, programar,  mejorar la productividad y así no desconcentrarte con el ruido externo.
• Luz: una buena iluminación ayuda a que tus ojos no se desgasten cuando estas frente al computador, a veces no basta con subirle todo el brillo a nuestro laptop, preferiblemente es bueno buscar espacios cerca de ventanas donde te de la luz del día.
• Elementos distractores: ¿son necesarios esos elementos que tienes al lado de tu equipo? recuerda que si tienes menos elementos en que pensar, tu mente se podrá enfocar más fácil en el trabajo. A veces esos elementos a nuestro al rededor le crean a nuestra mente una necesidad de observarlo y actual con ellos haciéndonos perder tiempo.

El fondo de escritorio de tu equipo.

Hablando de los elementos distractores quiero hablar sobre el escritorio, primero sobre el wallpapaper de fondo y luego sobre los iconos.

Wallpaper: tener una imagen de fondo de escritorio es bastante agradable, y puede hacer muy placentera nuestra estadía en el equipo, pero recuerda seleccionar muy bien la imagen, ten cuidado con los colores, y los elementos del mismo. una buena recomendación de wallpapers son los paisajes.

iconos: normalmente nos encontramos con que tenemos muchos iconos y accesos directos en nuestro escritorio, si los usas muy poco entonces considera borrarlos o meterlos en una carpeta, recuerda que los sistemas operativos traen una carpeta personal para el usuario donde podemos almacenar nuestros archivos, y el objetivo de esta carpeta es que nuestro escritorio no se llene de archivos.

Muéstranos tu escritorio:

Retomando la iniciativa del anterior artículo, quiero invitarlos a que nos dejen comentarios con sus espacios de trabajo y su fondo de escritorio.

Mi espacio de trabajo:

Mi fondo de escritorio:

 

Además, los invitamos a dejar sus recomendaciones y sugerencias para mejorar nuestra área de trabajo y cómo optimizar los recursos que tenemos para trabajar adecuadamente.

Síguenos en: @maestros | Fan page

Intel, Mandriva (en su tiempo), Motorola y empresas consultoras a nivel mundial como McKinsey, Deloitte, Accenture, T-Systems han operado en las capitales de América Latina dando servicios a las industria locales. Dando resultados como la gente de India y otros países de outsourcing del talento.

Ahora vemos como también ha venido el capital para encontrar aquellos proyectos con potencial de internacionalización con brillantes emprendedores y se han estado dando los resultados; empresas detrás de proyectos como PreyProject, Oja.la, Welcu y Ovia han tomado parte con iniciativas publicas y privadas para ir a competir al extranjero.

Visita para interactuar con el talento de América Latina

Tenemos las mismas oportunidades que proyectos que se crean en el extranjero con mayor acceso al capital tanto humano como económico; lograr crear empresas competitivas con una oferta de valor único. Ha costado años en que estos emprendedores como Tomas Pollak, Nicolas Orellana, Hernan Aracena , Jaime Romero y otros mas reciban invitaciones para participar como parte del ecosistema de Silicon Valley.

Todas estas son las razones que GeeksOnAPlane prepara en su segunda visita en América Latina y escoge ciudades como Miami,  México Distrito Federal, Sao Paulo y Buenos Aires para conocer a sus emprendedores, inversionistas locales y sobre todo gente que ha triunfado en estos mercados; les expliquen sus necesidades y donde ven las oportunidades para crear Startups.

Durante 10 días de Mayo los Geeks estarán invadiendo 3 ciudades de Latino América para poder construir lazos de negocios y sobre todo conocer el talento detrás de aquellos proyectos punteros de cada región. Los invito a estar al tanto esos días y darse el tiempo para conocer emprendedores, para escuchar sus historias y sobre todo compartir experiencias y vivencias del mundo del emprendimiento que tiene sus similitudes independiente de la distancia de nuestros países.

Apúntense para que sean participantes de GeeksOnAPlane como invitados y sobre todo den a conocer lo que están haciendo. Es la oportunidad de demostrar con acciones que aquí en América Latina también podemos crear empresas de tecnología con potencial mundial. No solamente consumimos, sino creamos para un mercado que esta por verse todo su potencial.

Síguenos en: @maestros | Fan page

Sin embargo, lo más importante de esta herramienta es la comunidad. Aunque los países con las comunidades más formadas son Alemania, Inglaterra en latinoamérica están creciendo cada vez más y hoy te queremos contar sobre ello.

Entrevistamos a referentes de varias comunidades OSM de latinoamerica: Fredy Rivera (Colombia), Gustavo Jarrín (Ecuador), Johnattan Rupire, Omar Vega, Miguel Vera León (Perú) y Hernán Ramirez (Venezuela).

Distintos países, una comunidad

Colombia

Fredy Rivera nos comentó que la comunidad funciona oficialmente desde mayo del 2008 con la creación de la lista de correo. Son aproximadamente 230 miembros suscritos, sin embargo calcula que unas 500 personas aportaron al mapa de Colombia en OSM.

“La comunidad OSM en Colombia ha priorizado desde el año 2010 la creación de un mapa que se pueda usar en condiciones de crisis” explicó Fredy y agregó que estas acciones se hacen coordinadas con el equipo humanitario (HOT Colombia) y otras organizaciones como OCHA de la ONU y el Banco Mundial.

Entre los eventos que realizan hay visitas de difusión en instituciones y universidades, también los llamados Mapping party que son “talleres donde se enseña a la gente a crear a sus propios mapas en OSM”. Además participan en actividades de mapeo en crisis como Rhok.org y Crisiscamp.

Ecuador

Gustavo Jarrín trabaja desde hace 8 años con OSM y nos contó que en un inicio era el único que conocía esta herramienta en su país por lo que se suscribía a foros intercontinentales. Afirmó que hay un gran aumento de desarrolladores locales, mayor acogida y preferencia por OSM.

La comunidad OSM en Ecuador, formada por desarrolladores y geografos, cuenta con 20 miembros registrados (en aumento) y para Gustavo esto significa un gran avance. Recalcó que el tema de interés se centra en la caracteristica Open Source de OpenStreetMap. Dicho espacio se utiliza para transmitir novedades, inquietudes y organizar el “Map Party”.

Perú

Desde el 2008 hay registro de la lista de correos de la comunidad OSM en Perú, según nos comentaron Johnattan Rupire y Omar Vega. “Se logró mayor participación desde una reunión convocada a mediados del 2010 por un compañero que venía de visita desde Oxford, quien nos donó un receptor GPS de parte de la comunidad en Inglaterra” nos contó Johnattan.

“La comunidad es pequeña, pero muy unida” afirmó Miguel Vera, son aproximadamente 6 miembros activos sin embargo “son varias las personas que contribuyen a cartografiar Perú desde diferentes partes del mundo” agregó Omar Vega.

Entre los eventos que realizan están las reuniones de coordinación y cartografiado, las “Mapping parties”, el Open Data Meetup Lima además de reuniones y conferencias en las universidades.

Venezuela

La comunidad OSM en Venezuela empezó a finales del 2008, “en esa época ya los teléfonos inteligentes empezaron a incluir GPS lo que me motivó a utilizar mapas digitales, incluso ir más allá y levantar data para el grupo de usuarios GPS de Venezuela” nos contó Hernán Ramirez.

“A partir de abril del 2009 empecé a levantar la data de Mérida y promocioné OSM entre mis amigos y colegas; llegué a la comunidad de GPS de Mérida que facilitó mucha data y permitió que hoy día el mapa de Mérida sea el más completo de Venezuela” nos dijo Hernán agregando que en seguida crearon el wiki de la comunidad y en agosto del 2010 el sitio OSM de Venezuela.

Existen casi 40 usuarios inscriptos en la lista de correo sin embargo según Hernán hay personas que colaboran que no están en el grupo. Algunos de los eventos y actividades que se realizan son la MapParty, charlas divulgativas, desarrollo de aplicaciones con OpenLayer, sistema monitoreo realizado para SAIME y otros proyectos que utilizan OSM como plataforma.

Desafios para OSM en latinoamérica

Preguntamos a nuestros entrevistados sobre los desafios que ven en cuanto a OSM en latinoamerica, Johnattan Rupire y Omar Vega afirmaron que:

Latinoamerica tiene una geografia muy interesante y diversa, pero lamentablemente muchos de estos lugares no están cartografiados aún

Agregaron que el tener cartografiado muchos de estos lugares permitiría a muchos otros proyectos que dependan del georeferenciado puedan usar estos mapas y ser de una gran utilidad en la difusión del proyecto también.

Todos coinciden en que falta más difusión de esta herramienta no solo para técnicos sino también para usuarios en general. Gustavo Jarrín menciona que si un usuario conoce de OSM solicitará aplicaciones que lo contengan y por ende se distribuirá este concepto entre los desarrolladores.

Para Miguel Vera es importante incrementar el número de miembros activos y completar el mapeo en detalle de las ciudades más importantes y eventualmente de ciudades cada vez más pequeñas hasta tener un mapa completo del país. Así también Fredy Rivera agrega que hay que “lograr que nuestros paises cuenten con una cartografia usable y libre en los terminos de cualquier uso inclusive comercial“.

El referente de Venezuela, Hernan Ramirez, destaca a Android como plataforma ideal para la utilizacion y desarrollo de apps de mapas y por último Johnattan y Omar dicen que hay que “convencer a los gobiernos para puedan contribuir con la información geográfica y que los datos que son elaborados con el impuesto de los ciudadanos pueda estar a disposición de estos.”

Síguenos en: @maestros | Fan page

¿Qué es un derecho?

Una de las definiciones que La Real Academia Española desgina a derecho es: “Facultad de hacer o exigir todo aquello que la ley o la autoridad establece en nuestro favor, o que el dueño de una cosa nos permite en ella.”

Entendiendo tal definición Frank La Rue, Relator Especial de las Naciones Unidas encargado de la protección del derecho a la libertad de opinión y expresión desde agosto de 2008, realizó un reporte escrito publicado el 3 de junio de 2011 declarando que el Internet se ha convertido en una plataforma importante dentro de la comunicación y la libre expresión de las personas por ello el acceso a Internet debería ser una prioridad para todos los países.

El papel de los gobiernos no es buscar formas de censurar Internet sino facilitar el acceso a la información que se maneja. Sin embargo, La Rue también marca algunas excepciones para la prohibición de la difusión de cierto contenido como: Pornografía infantil, discursos de odio, incitación al genocido y violencia.

¿Por qué es importante el acceso a Internet?

Ser un medio que nos permite la libertad de expresión es solamente hablar de una pequeña parte de todas las oportunidades que Internet nos ofrece. La tecnología avanza rápidamente, para países desarrollados esto es parte de su día a día pero para quienes no tienen el acceso representa un atraso para la sociedad. Es posible que lo sepamos pero no aceptemos que el uso de recursos digitales ya es una realidad.

Para los profesionales de la comunicación este derecho beneficiará de forma positiva y permitirá que la difusión de información llegue a más lectores con mayor facilidad y rapidez. Sin el acceso a Internet perderíamos alternativas de comunicarnos, oportunidades laborales y beneficios de aprendizaje.

Convergencia de medios

Stephanie Falla define al Periodismo digital como la convergencia de medios el cual reúne las características de ser interactivo, hipertextual y multimedial utilizando como plataforma de comunicación el Internet, el cual facilita la integración de diversos medios de comunicación (Prensa, Radio y Televisión) para transmitir información.

Para personas como los nativos digitales ya es una realidad, la publicación de contenido lo realizan a diario en las redes sociales, sin embargo, la tansición del periodismo tradicional al digital para algunos periodistas ha sido difícil y muchos son escépticos a una nueva forma de comunicar, a pesar de ello muchos periodistas y periódicos tradicionales han creado su versión digital, apostando mucho a esta “nueva” plataforma.

Nuevas formas de consumo

La forma en que consumimos información ha cambiado, cada vez hay menos interés en comprar la versión impresa de un periódico teniendo disponible de forma gratuita su versión digital. La cantidad de libros vendidos en Amazon sigue en aumento junto a dispositivos propios de lectura como el Kindle.

Pero escribir para la web no es solamente tomar el contenido de la versión impresa y trasladarlo a lo digital, se trata de conocer a nuestros lectores y suplir la necesidad de consumir información en diversos dispositivos móviles.

Tendencias laborales para los periodistas

Gracias a la evolución de la tecnología hemos encontrado nuevas oportunidades laborales en diversos campos, ahora orientados a la web. El Community Manager suple la necesidad de la administrar las redes sociales, el SEO posiciona a un sitio web dentro de los buscadores, el periodista debe aprender de edición, locución, escritura para utilizar al máximo la multimedialidad de la web, etc.

Hemos sido testigos de muchas ideas que han crecido hasta convertirse en empresas exitosas, es importante tener presente que podemos crear nuestro propio medio digital y no depender de una empresa editorial grande para difundir nuestra información, debemos pensar como emprendedores.

¡No tengo conexión!

Imagina el sin fin de oportunidades que tener acceso a Internet nos ofrece, a veces no soportamos la idea de estar sin conexión 5 minutos imagina qué hubiera sido de tu vida si nunca habrías estado expuesto a Internet. Esperemos el día en que existan computadoras con acceso a Internet como si fueran teléfonos públicos y todo individuo pueda disfrutar de tal derecho.

Síguenos en: @maestros | Fan page