jueves, 26 de abril de 2012

Creando un blog con django - parte 4

Después de una eternidad sin escribir y casi abandonar el tema de django, hoy por fin retomo el asunto. Hasta el momento tenemos los post clasificado por tags, pero un blog sin comentarios no es nada, así que hoy veremos como crear el formulario de comentarios.

En django existen dos formas de crear un formulario, una es crear cada campo manualmente y la otra es crearlos automáticamente basados en el modelo de datos.

Ya que casi siempre los formulario se usan para agregar/editar una tabla en una BD, y los campos del formulario reflejan los campos de la tabla, seria un desperdicio de tiempo crearlos manualmente.

Dejemos de hablar y empecemos a escribir código, editemos el archivo forms.py en el directorio de nuestra aplicación:
from django.forms import ModelForm #1
from blog.models import Comment #2

class CommentForm(ModelForm): #3
    """Formulario de comentarios"""
    class Meta: #4
        model = Comment #5
        exclude = ("post","deleted") #6

Hora de explicar lo que hemos hecho:
  1. Importamos ModelForm, la base para los formularios basados en modelos de datos.
  2. Importamos el modelo para el que se creará el formulario
  3. Creamos una subclase de ModelForm.
  4. En la clase Meta especificamos como crear el formulario
  5. model: modelo en el que se basa el formulario.
  6. exclude: campos a excluir, en este ejemplo post lo asignamos según el articulo desde el que se envió el comentario y deleted lo decidimos en la pagina de administración si es un comentario insultante. Si son muchos los campos a excluir podemos hacer lo contrario y especificar los que se deben incluir.
    Ahora podemos incluir el formulario en la vista single:
    # Archivo views.py
    from blog.models import Post, Tag, Comment
    from blog.forms import CommentForm
    ...
    # la función recibe el numero capturado
    def single(request, id=0):
        # recuperar post según id
        post = Post.objects.get(id=int(id))
        # Crear formulario
        form = CommentForm()
    
        return render_to_response("single.html", locals())
    
    Para crear el formulario se instancia el objeto adecuado y en la vista se usa esta instancia para mostrar el formulario:
    {# plantilla single.html #}
    {% extends 'base.html' %}
    
    {% block main_content %}
        {% include 'include/article.html' %}
        {# necesitamos crear el tag form #}
        <form action="" method="form">
            {{ form }}
        </form>
    {% endblock %}
    
    Con esto veremos el formulario en nuestro blog, lo llenamos y enviamos...
    Wow un error. Django requiere que incluyamos protección contra ataques csrf, este tipo de ataque permite que alguien engañe a un usuario registrado para enviar datos a nuestro sitio usando un formulario en otra pagina web. Afortunadamente django tiene todo lo necesario para protegernos con unas cuantas lineas de código.
    # Archivo views.py
    from blog.models import Post, Tag, Comment
    from blog.forms import CommentForm
    # importamos el decorador
    from django.views.decorators.csrf import csrf_protect
    # importamos render
    from django.shortcuts import render
    
    ...
    # aplicamos el decorador función que recibe datos de formulario
    @csrf_protect
    def single(request, id=0):
        # recuperar post según id
        post = Post.objects.get(id=int(id))
        form = CommentForm()
        
        # usamos render en lugar de render_to_response
        return render(request, "single.html", locals())
    
    Ahora incluimos el tag {% csrf_token %} dentro del formulario en la plantilla single.html. Esto crea un elemento input oculto con un token único que se verifica al enviar datos al servidor, si este no coincide, se produce un error 403 (prohibido) y tenemos una app algo mas segura.

    Ok, ya podemos enviar datos del formulario al servidor, hora debemos validarlos y guardarlos en la BD.
    # Archivo views.py
    @csrf_protect
    def single(request, id=0):
        # recuperar post según id
        post = Post.objects.get(id=int(id))
        # recuperar comentarios de este post
        comments = Comment.objects.filter(post=post)
    
        # Si la petición es POST es porque enviaron el formulario
        if request.method == "POST":
            # Creamos una instancia del modelo Comment asignado el post actual
            comment = Comment(post=post)
            # Creamos una instancia del formulario con los datos recibidos
            form = CommentForm(request.POST, instance=comment)
            
            # Validamos los datos
            if form.is_valid():
                # Guardamos el comentario en la BD
                form.save()
                # Enviamos al usuario de nuevo al post
                return HttpResponseRedirect("/post/{0}".format(slug))
        
        # De lo contrario creamos un formulario vacío
        else:
            form = CommentForm()
        
        return render(request, "single.html", locals())
    
    Podemos notar algunas cosas:
    1. Validamos el formulario con el método is_valid que no definimos. ¿como es esto posible?; Al crear el modelo Comment especificamos el tipo de datos admitidos, el formulario "sabe" que si esto datos no corresponden, el formulario contiene errores.
    2. Para guardar los datos usamos form.save y no comment.save. Esto se debe a que hay datos que no están incluidos en el formulario (post) pero si en la instancia comment y viceversa, por esto pasamos comment al formulario en el momento de crearlo.
    Solo resta mostrar los comentarios, editamos la plantilla single.html:
    {# plantilla single.html #}
    {% extends 'base.html' %}
    
    {% block main_content %}
        {% include 'include/article.html' %}
        {% for comment in comments %}
          <div class="comment">
              <div class="user">{{ comment.name }} dijo:</div>
              <div class="body">{{ comment.body }}</div>
              <small>{{ comment.date|date:"d-m-Y" }}</small>
          </div>
        {% endfor %}
        {# necesitamos crear el tag form #}
        <form action="" method="form">
            {{ form }}
        </form>
    {% endblock %}
    
    Con esto solo falta crear el sitio de administración para agregar post y moderar los comentarios y tendremos un blog terminado. Estén pendientes por la ultima parte de esta serie que seguro saldrá antes que se acabe el mundo este 21 de diciembre XD.

    miércoles, 28 de marzo de 2012

    while (fracaso) { try{do_something} catch(e){ continue; } }


    Después de varios "fracasos" puedo decir con seguridad que la parte difícil de programar no es tener una idea y desarrollarla, no porque sea fácil, sino porque entre entre mas dificultad presente el problema mas nos entusiasmamos y a pesar de todo lo disfrutamos (al menos yo).

    Pero a la hora de "vender" el producto y lo pongo entre comillas ya que no lo digo en el sentido de intercambiarlo por dinero sino hacer que las personas lo usen, recomienden... todo va mal. Por poner ejemplos:

    ConceptMap: una aplicación para crear mapas conceptuales que desde su lanzamiento ha tenido la increíble estadística de 2 personas afiliadas y 1 mapa conceptual creado.

    jsaw5: un juego que permite crear rompecabezas de hasta 100 fichas usando cualquier imagen y compartirlos con amigos usando una url corta, que empezó muy bien pero a medida que pasan los días veo como las estadísticas en analytics van cayendo.

    Y eso que estas aplicaciones son GRATIS, ahora no me imagino lo difícil que debe de ser atraer usuarios que paguen por usar tu programa.

    No es solo la falta de experiencia en marketing y esas cosas, sino que la tarea en sí resulta molesta a diferencia de programar que disfruto aun cuando me saca canas verdes.

    Tal vez no tengo talento para esto, tal vez nunca pueda llegar a crear una aplicación "popular", pero por el momento seguiré intentando.

    Alguien mas se siente de esta forma, algún consejo.

    jueves, 8 de marzo de 2012

    jsaw5: Crea rompecabezas personalizados


    Ya llevo tiempo sin escribir, y es que en estos días han pasado muchas. Ahora que tengo tiempo libre (ya que estoy desempleado) me puse en la tarea de crear un juego en javascript y HTML5: jsaw5.

    Actualización: el demo fue movido a dropbox

    En jsaw5 podrán crear, resolver y compartir rompecabezas personalizados con amigos en twitter y facebook. Espero que lo visiten y den sus opiniones, aun debe tener varios errores pero si esperaba a que fuera "perfecto" 

    En el proceso de creación agregue algunas mejoras a canvas-event-js las cuales espero hacer disponibles en cuanto pueda.

    miércoles, 28 de diciembre de 2011

    Visor de imágenes para xkcd

    Una de mis tiras cómicas favoritas es xkcd, y desde ya hace tiempo quería descargarme todas las tiras para tenerlas en el disco duro. Si han leido xkcd seguro sabran de los textos adicionales que Randall Munroe pone en el atributo title de las imágenes, este texto es complementario a la tira y en muchas ocasiones mas gracioso que la tira misma.

    Así que si descargaba las tiras tenia que hacerlo con todo y titulo. Tuve un tiempo libre esta navidad y me puse a recolectar información de como hacerlo, lo primero era descargar las imágenes y guardar el texto del tooltip en los metadatos de la imagen, para esto me fue de mucha ayuda este articulo donde se explica como hacerlo usando la libreria PIL.

    Lo siguiente era crear un visor de imágenes que mostrara los tooltip, algo complicado y mas teniendo en cuenta que esta es la segunda interfaz gráfica "seria" que hago, pero encontré muy buenos recursos como este libro online sobre tkinter con muy buenos ejemplos, ademas de un script que implementa un tooltip que me cayo de perlas.

    Luego de varias horas de pelearme acomodando los widget (con pack y grid), he aquí el visor de imágenes junto con todas las tiras hasta la fecha (1-995).
    Si bajan el código fuente necesitaran instalar las siguientes librerías:
    • PIL (en Windows y Linux)
    • ImageTk (solo en Linux: python-imaging-tk)
    • Tkinter (solo en Linux)
    Si tienen alguna sugerencia no duden en dejarla en los comentarios, siempre es bueno saber en que mejorar.

    lunes, 26 de diciembre de 2011

    Actualización: canvas-event-js 0.2

    Después de meses sin actualizar, he aquí algunas cosas nuevas que pueden encontrar en canvas-event:
    Ideas que tengo pero no he implementado:
    • Drag-n-Drop live para evitar llamar drag en cada objeto creado, ya que demasiados callback pueden poner lenta las aplicaciones.
    • moveUp, moveDown, toFront, toBack: para mover objetos entre capas (como en PowerPoint). 
    Todo esto lo pueden encontrar en el repositorio de github a donde he movido el proyecto, donde ademas pueden dejar sus sugerencias y reportes de errores, su ayuda es muy importante y siempre bien recibida.

    P.D.: Has creado alguna aplicación usando canvas-event, deja el link en los comentarios (simple curiosidad *¬*)

    viernes, 23 de diciembre de 2011

    Creando un blog con django - parte 3

    En la parte anterior dejamos la base de datos lista, es momento de crear las plantillas para visualizar estos datos.
    Lo primero que haremos es configurar el directorio donde estaran guardas las plantillas. Creamos el directorio templates en la raíz del proyecto y editamos el archivo settings.py.
    .....
    import os
    
    TEMPLATE_DIRS = (
        os.path.join(os.path.dirname(__file__) ,"templates"),
    )
    ....
    
    Así el script puede encontrar el directorio templates aun cuando cambiemos de ubicación la carpeta del proyecto. Ahora editamos el archivo urls.py para incluir la url a la pagina.
    ....
    urlpatterns = patterns('',
        (r'^$', 'blog.views.index'),
        ....
    )
    
    Con esto le decimos a django que toda petición hecha a la raíz del blog sera manejada por la función index ubicada en el archivo views, la cual luce así:
    from django.shortcuts import render_to_response
    
    def index(request):
      return render_to_response("index.html")
    
    Al visitar la raíz del sitio, django llamara la función index pasando como argumento un objeto request que contiene información sobre la solicitud (datos POST y GET entre otros). La función index realizar algún proceso y retornar un objeto response.

    Si iniciamos el servidor de desarrollo y entramos a la dirección localhost:8000 veremos un mensaje de error como el de la imagen ya que la plantilla index.html aun no existe, así que manos a la obra.
    <!DOCTYPE HTML>
    <html lang="es-ES">
    <head>
     <title>Mi Blog</title>
    </head>
    <body>
    <!-- hasta aquí siempre es igual -->
    <h1>Hola Django</h1>
    </body>
    
    No muy útil, pero por el momento es todo lo que necesitamos. Imagine que creamos otras plantillas para post individuales, contacto, faq, quejas... debemos repetir la cabecera en cada una de ellas.

    El sistema de plantillas de django permite crear plantillas base con bloques que luego pueden ser reemplazados por las plantillas que heredan de ésta; para tal efecto creamos la plantilla base.html:
    <!DOCTYPE HTML>
    <html lang="es-ES">
    <head>
     <title>Mi Blog</title>
    </head>
    <body>
    {% block content %}
    {% endblock %}
    </body>
    
    Y editamos la plantilla index.html para que extienda base.html:
    {% extends "base.html" %}
    {% block content %}
    <h1>Hola Django</h1>
    {% endblock %}
    
    Ok, teniendo una idea general del sistema de plantillas, seguimos con la pagina inicial del blog empezando por editar el archivo views.py.
    from django.shorcuts import render_to_response
    from blog.models import Post
    
    def index(request):
        # recuperamos 5 primeras entradas
        posts = Post.objects.filter()[:5]
        return render_to_response("index.html", locals())
    
    Cada vez que visitemos a la raíz del blog se consultaran los primeros 5 post y se pasaran a la plantilla index.
    {# plantilla index.html #}
    {% extends "base.html" %}
    
    {% block content %}
    {% for post in posts %}
        <h1><a href="/{{ post.id }}">{{ post.title }}</a></h1>
    <p>{{ post.pub_date}}</p>
    {{ post.body }}
        {# esto no es muy eficiente* #}
        {% for tag in post.tags.filter %}
            <a href="/tags/{{ tag.tag }}">{{ tag.tag }}</a>
        {% endfor %}
    {% endfor %}
    {% endblock %}
    
    * Extraer las etiquetas de esta forma no es eficiente ya que al llamar a filter (5 veces) se hace una nueva consulta a la base de datos, algunas soluciones se pueden encontrar aquí.

    Con esto la pagina principal esta lista. Sigamos con la pagina individual, veremos que al trabajar con django se sigue mas o menos el mismo patrón:
    # archivo urls.py
    urlpatterns = patterns('',
        (r'^$', 'blog.views.index'),
        # expresión regular que captura el numero después de post/
        (r'^post/(?P<id>\d+)$', 'blog.views.single'),
    )
    
    # Archivo views.py
    ...
    # la funcion recibe el numero capturado
    def single(request, id=0):
        # recuperar post según id
        post = Post.objects.get(id=int(id))
    
        return render_to_response("single.html", locals())
    
    {# plantilla single.html #}
    {% block content %}
        <h1><a href="/{{ post.id }}">{{ post.title }}</a></h1>
        <p>{{ post.pub_date}}</p>
        {{ post.body }}
        {# esto no es muy eficiente* #}
        {% for tag in post.tags.filter %}
            <a href="/tags/{{ tag.tag }}">{{ tag.tag }}</a>
        {% endfor %}
    {% endblock %}
    
    Notan algo raro? el código de single.html e index.html luce muy similar; podemos eliminar el código repetido moviéndolo a otra plantilla (article.html) que luego incluimos en estas.
    {# plantilla article.html #}
    </div>
        <h1><a href="/{{ post.id }}">{{ post.title }}</a></h1>
        <p>{{ post.pub_date}}</p>
        {{ post.body }}
        {# esto no es muy eficiente* #}
        {% for tag in post.tags.filter %}
            <a href="/tags/{{ tag.tag }}">{{ tag.tag }}</a>
        {% endfor %}
    </div>
    
    Ahora editamos las plantillas index.html y single.html para que utilicen article.html.
    {# plantilla inde.html #}
    {% extends 'base.html' %}
    
    {% block main_content %}
        {% for post in posts %}
            {# pasamos la variable post como argumento #}
            {% include 'include/article.html' with post=post %}
        {% endfor %}
    
    {% endblock %}
    
    {# plantilla single.html #}
    {% extends 'base.html' %}
    
    {% block main_content %}
          {% include 'include/article.html' %}
    {% endblock %}
    
    Con esto damos por terminado esta parte. No se olviden de comentar.

    P.D.: Procurare tener la próxima parte mas rápido.

    viernes, 9 de diciembre de 2011

    Actualización mget

    Debido al rediseño de megaupload mget ha dejado de funcionar, el problema se debe específicamente a que el link de descarga ya no se identifica con el id downloadlink sino con la clase download_regular_usual, ademas el tiempo de espera ahora es de 60 segundos.

    Por el momento no tengo como arreglar la versión para windows pero la de linux ya esta lista, solo hay que reemplazar el archivo antiguo y dar permisos de ejecución.
     
    © 2009 NovatoZ. All Rights Reserved | Powered by Blogger
    Design by psdvibe | Bloggerized By LawnyDesignz