David Leadbeater ha implementado un servicio que devuelve artículos resumidos de Wikipedia via el record TXT del servicio DNS. (Ver Wikipedia over DNS, via Hackzine.)

Lo que me ha parecido interesante aquí es el uso no convencional del servicio DNS. Leadbeater está usando el subdominio como si fuera la llave de un diccionario (me refiero a diccionario en el sentido de hashkey). Envía una solicitud DNS preguntando por el dominio key.example.com, y el servidor DNS devuelve la data asociada a key.

Leadbeater no da el código del programa (por lo menos no lo he encontrado en la página), pero no sería complicado escribir un servicio parecido en Python (ver, por ejemplo, Servidor Fake DNS en Python)

Otra posibilidad es usar el servicio DNS para crear un tunnel entre nuestro equipo, supuestamente dentro de una “red hostil”, y un servidor remoto de nuestra propiedad que se encuentre fuera de esta red. Este tunnel permite atravesar, en casi todos los casos, las restricciones que tenga la “red hostil” para acceder a Internet, sin que nadie pueda evitarlo fácilmente. Esto se llama IP-over-DNS.

Esta cita de dnstunnel.de da idea de algunos usos:

Did you ever sit at the airport or at a cafe and there was a unencrypted wireless access point nearby, but whenever you wanted to visit a site their website would pop up asking for a fee to use the internet through their AccessPoint (aka. Captive Portal)?

(Esto, casi seguro, no es legal y no me parece un uso correcto. Pero hay otros usos que sí lo son, y es algo que debe tener en cuenta el administrador de la red)

Algunos links interesantes que tienen que ver con este tema y con IP-over-DNS:

• DNS tunneling
• DNSTunnel
• Un tutorial sobre /c
• DNS tunneling
• NSTX (Nameserver Transfer Protocol) Makes it possible to create IP tunnels using DNS queries and replies for IP packet encapsulation where IP traffic other than DNS isn’t possible.
• iodine. Hace lo mismo que NSTX pero funciona en MacOs. Aquí un tutorial sobre iodine.
• El FakeDNS Server escrito en Python que menciono arriba (el código podría ser más elegante… parece C)

Estaba investigando cómo instalar Amarok en MacOs, pero finalmente no hizo falta, pues encontré (mejor dicho, re-descubrí) Songbird. Es gratis, hay versiones para MacOs, Linux y Windows. Además de una interfaz pulida, Songbird, como Amarok, permite extensiones (por ejemplo, el LyricsPlugin, como el que hay para Winamp o para Windows Media Player, y similar al que mostraba en el post anterior sobre Amarok). Y Songbird, al igual que Amarok, respeta mi estructura de directorio: no se empeña en mover las canciones a “su” carpeta. Recomendado.

<a href=”http://www.zoia.org/blog/wp-content/uploads/2008/07/songbird.png” title=”songbird.png rel=”lightbox”>

Cuál es el problema que quieres resolver

El post podría terminar con la foto de arriba, pero quería hacer unas consideraciones sobre dos enfoques distintos en el desarrollo de software.

Tanto Amarok como Songbird se proponen objetivos parecidos: ser una alternativa a los media players tradicionales, proporcionando una buena experiencia de uso. De sus respectivos websites:

• Amarok is the music player for Linux and Unix with an intuitive interface. Amarok makes playing the music you love easier than ever before – and looks good doing it
• Songbird is a highly customizable alternative to traditional desktop media players

La version 1.x de Amarok para Linux cumple bien este objetivo. Basta seleccionar Amarok en el instalador de paquetes para que Linux descargue Amarok y lo instale. Y funciona bien.

Desde hace algún tiempo el equipo de desarrollo de Amarok viene anunciando la versión 2.0, que correría también en MacOs (ver el wiki) y en Windows. Sin embargo, ahora que la versión 2.0 está en Alpha (es decir, se puede instalar, pero todavía tiene bastante por pulir), empiezan a decir que las versiones de MacOs y Windows no son una prioridad, porque la mayoría de sus desarrolladores trabajan con software libre. ¿Y antes no era así?

También están los cambios que se introducen en la versión 2.0 de Amarok. El FAQ explica sin empacho que no funcionarán los antiguos scripts (las extensiones); que lo más seguro es que los usuarios de la versión 1.x pierdan sus playlists y los ranking de las canciones… salvo que uno de sus desarrolladores logre terminar un programa para convertirlos. Y, lo siento, se podrán ver videos pero no habrá un manejador de video propiamente. Los videos serán un archivo más (¿sólo que sin ranking, etc.?).

Si la idea de Amarok es una mejor experiencia para el usuario, ¿por qué romper con todo lo anterior? Si el formato interno de los playlists y ranking cambia, ¿no sería una característica importante que Amarok 2.0 reconozca sin ninguna falla, de modo transparente para el usuario, los de la versión 1.x? No, lo que nos dicen es que un desarrollador está haciendo algo en esa línea, quizá lo incluyan, quizá no.

Mi diagnóstico es que el equipo de Amarok ha perdido de vista qué necesidad resuelve su programa. Están tan preocupados de que funcionen sus unhidden biases, que no se dan cuenta que la versión 2.0 quizá resuelva menos necesidades que la versión 1.x.

Songbird y Los Pioneros de lo Inevitable

Veamos el modelo de Songbird. Para comenzar, vale la pena darle una mirada al About Us de Songbird (click en la foto) y en general a la página. Con ver las oficinas ya me caen bien estos señores. Además del look profesional de la página, tienen “algo” de experiencia en desarrollo de software y productos terminados (entre otros, Winamp y el Yahoo! Music Engine.

Songbird ni siquiera está en la versión 1.0, y ya ofrece instaladores para Linux, MacOs y Windows. Las tres distribuciones están siempre disponibles. Las tres funcionan. Las tres usan las mismas extensiones. Las nuevas versiones no destruyen tus playlists, ni malogran tus rankings.

Por supuesto, quizá no puedo conectar Songbird a un servidor PosgreSQL… pero ¿hace falta?

Songbird tiene dos websites distintos: uno para los usuarios finales, otro para desarrolladores. Cada página tiene su propio enfoque, porque pretende resolver distintas necesidades. Si lo que te interesa es hackear un poco (que me parece es lo que les intersa a los desarrolladores de Amarok), o colaborar con el proyecto, la página de desarrollo de Songbird tiene tutorials, documentación de los APIs, explica cómo desarrollar extensiones… tienes un website que resuelve eso sin complicar a los demás usuarios, la gran mayoría.

Amarok, en cambio, empieza ofreciendo una página para usuarios finales, pero termina siendo una página para desarrolladores… esperemos que no pase lo mismo con la versión 2.0 de Amarok.

Desde hace unos meses Game Developer ha empezado a ofrecer subscripción electrónica. Muy conveniente.

Aquí se puede ver un ejemplar antiguo de muestra: http://gamedeveloper.texterity.com/gamedeveloper/sample/

Hace unos días Google lanzó Google App Engine. Me ahorro detalles que ya se han comentado en otros sitios.

Por ahora estoy “en cola” esperando una cuenta de prueba. Algunos detalles: el lenguaje de programación es Python 2.5, permite trabajar con la mayoría de Python web frameworks y para comodidad del desarrollador incluye Django 0.96.1.

El video de abajo muestra una aplicación sencilla. (No es ninguna novedad, lo saqué de la página de Google App Engine.) El framework, en este caso, no es Django (sí usa los templates de Django), pero a los que hayan programado con Django el código les resultará algo familiar.

Encontré esta entrevista a Alex St. John, que estuvo en el proyecto inicial de DirectX (la librería de gráficos para juegos de Microsoft). Es de hace un año, pero muy buena.

Hace unos días ActiveState ha sacado una versión open source de Komodo Edit, bajo los mismos términos que la licencia de Firefox. Esta decisión tiene sentido, pues Komodo Edit comparte parte del código fuente base de Mozilla.

Desde hace años, ActiveState desarrolla herramientas para programar en Perl, Python, PHP, Ruby y otros. También aloja varios “Cookbooks” (recetarios) en su website, por ejemplo, el imprescindible Python Cookbook.

Un detalle interesante, relacionado precisamente con Mozilla, son las extensiones que usa Komodo Edit. Basta ver el segundo screenshot para entender a qué me refiero: son extensiones escritas en XUL, el mismo sistema que usan Firefox y Thunderbird. Y, otra cosa que se puede ver en el screenshot, Komodo viene con una extensión para desarrollar con Django.

Hay versiones para Linux, MacOs y Windows, y se puede descargar del website de ActiveState.

Some interesting examples on how to handle file uploads using Django:

• Code snippet posted on Djangosnippets. The file is saved by declaring a save() method in the form class. This method is invoked when calling form.save(), which is standard Django newforms practice. (Note that this snipped uses clean_data. As of Django version 0.96, clean_data has been renamed to cleaned_data, so you will have to change the code or it won’t work)
• Django image upload and validation. The author uses a model for the file and its related data. The uploaded file is saved by calling the save_FOO_file method. (This method is automatically provided by Django for fields declared as models.ImageField or models.FileField in the model. See the db-api documentation.)
• Django image upload, form_for_instance and monkey-patching. The example code creates a form class from request.user by calling form_for_instance. The resulting class in then monkey-patched to insert the avatar image validation code. (Although the code is interesting the monkey patch seems unnecessary. I wouldn’t mind inserting the avatar validation method in a UserProfileForm class derived from form.Forms. The code would be certainly clearer: I think KISS takes precedence over DRY in this case.)

Interesting, there seems to be no easy way of limiting the uploaded file size. The file can be rejected at validation time, but the data would have already been transfered.

A file upload recipe

After reading those posts, I think that a good recipe for handling file uploads in Django would be:

• Write a django model for the uploaded file and its related data. Using a Django model makes sense, because it is usually necessary for the application to keep track of the uploaded files.
• Write a subclass of form.Forms and declare a clean_FOO method for each models.FileInput or models.ImageInput fields declared in the model class. These clean_FOO methods are used to validate the uploaded files.
• use a django view to receive the POST data, or display the form if no data is posted or errors are found.
• validate the uploaded file or files by triggering the standard django newforms validation mechanism: is_valid().
• save the file or files getting the data directly from the request.FILES object, by writing a save() method for the subclassed form or by calling save_FOO_file for the model instance.

A simpler way to upload a file

The following short Django example uses no data models, does no data validation, and saves the file directly to disk using python standard file functions. It is just a simple test I wrote to get familiar with the request.FILES object. This is not production code: it could be used to execute an arbitrary script on the server. The directory where the file is to be saved must be writable by the user that is running the Django server script. (The example uses MEDIA_ROOT as defined in settings.py.)

file: views.py

from django import http
from django import newforms as forms
from django.shortcuts import render_to_response
from djangotest.settings import MEDIA_ROOT



class SimpleFileForm(forms.Form):
    file = forms.Field(widget=forms.FileInput, required=False)


def directupload(request):
    """
    Saves the file directly from the request object. 
    Disclaimer:  This is code is just an example, and should
    not be used on a real website.  It does not validate
    file uploaded:  it could be used to execute an 
    arbitrary script on the server. 
    """

    template = 'fileupload.html'

    if request['method'] == 'POST':
        if 'file' in request.FILES:
            file = request.FILES['file']

            # Other data on the request.FILES dictionary:
            #   filesize = len(file['content'])   
            #   filetype = file['content-type'] 

            filename = file['filename']

            fd = open('%s/%s' % (MEDIA_ROOT, filename), 'wb')
            fd.write(file['content'])
            fd.close()

            return http.HttpResponseRedirect(' upload_success.html')
    else:
        # display the form
        form = SimpleFileForm()
        return render_to_response(template, { 'form': form })

file: fileupload.html

{% extends "base.html" %}

{% block body  %}
     <h1>Upload a file</h1>
     <form action="." method="post" enctype="multipart/form-data">
             {{ form }}
             <input type="submit" value="Upload" />
     </form>
{% endblock %}

The Django newforms documentation has been updated some days ago. It includes an explanation on how to use form_for_models and form_for_instance and provides some examples.

More interesting, however, is when not to use them: “If you want to create a form whose fields map to more than one model, or a form that contains fields that aren’t on a model, you shouldn’t use these shortcuts.”

Desde hace algunas semanas estoy aprendiendo Lisp. Estoy bien cómodo programando en Python, y he aprendido bastante dando clases de Java. Pero Lisp tiene algunas cosas que no tienen esos lenguajes (y ningún otro, al parecer), y que me interesa aprender, en particular la capacidad de extender la sintaxis del lenguaje como práctica habitual de programación. Esto en Lisp se llama Macros, y no tienen nada que ver con los macros como se entienden en C/C++. Como siempre, hay que sacar tiempo de donde no hay, así que estoy yendo más lento de lo que quisiera.

Los ensayos de Paul Graham son muy buenos y sugerentes, y el libro Hackers and Painters tampoco tiene pierde. Obviamente no quiere decir que coincida 100% con lo que dice, pero habla bastante de Lisp, por no decir que está absolutamente entusiasmado con Lisp.

Estoy usando dos libros: Practical Common Lisp, de Peter Siebel, que se puede descargar sin costo del website de APress. Y ANSI Common Lisp, de Paul Graham, que compré en Amazon.

Menos bla,bla,bla, quiero empezar a escribir programas…

Primera tarea, instalar alguna versión de lisp en la computadora. En Ubuntu:
$ sudo apt-get install clisp clisp-doc Ya tenemos lisp en la computadora. Ahora basta escribir: $ clisp

Practical Common Lisp recomienda usar Emacs como editor de texto/entorno de desarrollo y la extensión SLIME (Superior Lisp Interaction Mode for Emacs). (Más información sobre Emacs, ver Wikipedia.) Por ahora voy a seguir los consejos del libro, así que a instalar Emacs y Slime.

Intenté usar la versión de Emacs que está en los repositorios de Ubuntu, y que se integra con Gnome. Pero las letras en la pantalla se veían francamente horribles. Creo que la pantalla del Macro Assembler que tenía en la Atari 800XL que usaba en el siglo 20 se veía mejor. Bien, siempre hay soluciones. Buscando en Google “pretty emacs”, encontré esta página, donde se explica cómo instalar una versión de Emacs más reciente, compilada para que haga un render decente de los fonts. En la imagen se puede ver el resultado.

Segundo paso, aprender lo suficiente de Emacs como para crear un programa, guardarlo en un archivo y compilarlo. Emacs tiene fama de ser poco amigable, y lo es. En este post Erik Rasmussen explica con gracia cómo al comienzo no se explicaba por qué si Lisp es un lenguaje superior e increíble, es tan poco usado. Al menos eso es lo que se preguntaba él hasta que intentó usar Emacs.

El némesis de Emacs es vim, otro editor muy común en Linux. vim es poderoso. He desarrollado websites enteros usando vim. Incluso cuando estoy usando un procesador de texto me sorprendo a veces teclando “:w”, que es el comando de vim para guardar el archivo. Pero la verdad que entre perder tiempo tratando de que Lisp y vim se entendieran, preferí dedicar veinte minutos a seguir el tutorial de que trae el mismo Emacs. (Se accede al tutorial presionando Ctrl-h t. O, como dicen en Emacs, C-h t.) Y confirmado: veinte minutos bastan para empezar y moverse en Emacs.

Uno de los comentarios del post de Rasmussen dice que hay un plugin de lisp para Eclipse: más adelante le daremos una oportunidad.

Tercer y último paso, instalar SLIME. Slime es un entorno de desarrollo para programar en Lisp dentro de Emacs. En Ubuntu se puede instalar escribiendo: $ sudo apt-get install slime Como se explica aquí, también es necesario añadir lo siguiente al archivo ~/.emacs: (setq inferior-lisp-program “/usr/bin/clisp”) (add-to-list ‘load-path “/usr/share/emacs-snapshot/site-list/slime”) (require ‘slime) (slime-setup) Listo. Ahora sí, en Emacs: M-x slime, y aparece SLIME.

Y podemos escribir: (hello-world).

Most of the examples I have found on the web about replacing the default Django newforms widgets use hard coded values for the list of choices the widget displays. But those hard coded examples fall short when the widgets are bounded to many-to-many fields or to foreign keys in the model class. That is, when the list of choices is generated dynamically at run time, read from a database table.

The solution is obvious simple: fetch the dictionary of choices from the original widget, and use it as a parameter for your new custom widget.

It sounds simple, and it is. But it took me some time to figure out how to do it. The Django newforms lilbrary documentation is still work in progress, at least at the time of this writing. I could not found where the original widgets were stored in the Form instance. Thankfully, Django is an open source project, and Python has an interactive shell mode. Inspection of the source code and regression tests, and some playing with the Python shell is really an enlightening process. Anyway, I am posting this on the blog for further reference. I also include a working example of a sample Django blogging application I wrote for testing: pretty basic, but it and ilustrates, among other things, the use of custom widgets with dynamic choices.

Maybe the explanaition is “over-verbose”… suggestions accepted.

Don’t hit the database twice

Consider the following model class:

# models.py Models for django blog application
from django.db import models

class Tag(models.Model):
    tag = models.CharField(maxlength=50)

class Author(models.Model):
    name = models.CharField(maxlength=100)
    email = models.EmailField()

class Article(models.Model):
        (...)
    author = models.ForeignKey(Author)
    tags = models.ManyToManyField(Tag)

The standard method for displaying a form for the model class in a webpage is to subclass forms.Form, create an instance of the subclass and return the rendered the template. Examples of this can be found on the Django website and on the web.

Django newforms provides two methods that simplify the subclassing of forms.Form: form_for_instance and form_for_model. Both methods return a new class: a subclass of Form, more precisely, tuned to your model class or model instance. If you have a model class or model instance with a many-to-many relationship, and you don’t mind displaying the relationship as a listbox on the webpage, then these two methods will take care of querying the database, building the list of options and feeding it to SelectField or a SelectMultipleField widget.

          #  ArticleForm is a subclass of form.Form
          ArticleForm = forms.models.form_for_model(Article)

The next step is to create an instance of ArticleForm, and return the rendered template:

        form = ArticleForm()
        return render_to_response('post.html', { 'form': form })

I don’t like lists for multiple option selection, at least not in webpages. I prefer checkboxes. It takes some CSS tweaking to render them correctly and evenly spaced on the webpage, but it greatly enhances the user experience.

The class generated by form_for_model (and by form_for_instance) stores the widgets in a variable named base_fields (a dictionary). This makes it simple to replace any of the default widgets with any other widget, provided it makes sense to do so. For example, the following code replaces the author and tags widgets with a RadioSelect widget and a CheckboxSelectMultiple widget:

        ArticleForm.base_fields['tags'].widget = CheckboxSelectMultiple(choices= ... )
        ArticleForm.base_fields['author'].widget = RadioSelect(choices= ... )

The only thing left is to provide the list of choices that both CheckboxSelectMultiple and RadioSelect constructors expect as one of their parameters. One way to build such lists is to query the database and fetch the entries for the Tag and Author classes. Something like tagChoices = Tag.objects.all() and authorChoices = Author.objects.all(). Convert the resulting queryset to a dictionary and use it as a parameter to the RadioSelect widget constructor.

But this is querying the database twice and for the same data each time the form is displayed on the webpage: once for the original SelectMultiple widget, and then again for the custom widget. And it would be a shame to have your name on such code… Obviously, this can be avoided by retrieving the list of choices from the original SelectMultiple widget and using it as the list of choices for our custom widget:

        ArticleForm = forms.models.form_for_model(Article)

        ArticleForm.base_fields['tags'].widget = CheckboxSelectMultiple(
                choices=ArticleForm.base_fields['tags'].choices) 

        ArticleForm.base_fields['author'].widget = RadioSelect(
                choices=ArticleForm.base_fields['author'].choices)

        form = ArticleForm()
        return render_to_response('post.html', { 'form': form })

That’s it. The Author SelectField gets replaced by radio buttons, and the Tag MultipleSelectField by some nice checkboxes. The database gets hit only once. Nothing to be ashamed of.

A complete example

Updated 2007-5-5: added editpost.html, which was not included by mistake.

The following is a test blog application I wrote. It uses form_for_instance and form_for_model to define the proper subclass of form, then replaces the standard widgets with custom ones. The widgets load the Author and Tags choices dynamically. In addition, creation and edition of the blog posts are handled by the same method. A regular expression in urls.py converts web page names to slugs as registered in the database, so permalinks are effectively implemented.

This blogging app is really basic: the Django admin interface is needed to add new tags and authors; no authentication; post slugs have to be hand created; no plugins; etc. But deactivate the edit line in urls.py, use css to pump up the desigh, edit your posts using the admin interface, and you have a Django-powered miniblog you can start customizing. Maybe pass the form with the article content to another method, before rendering the template, and write some plugins to pre-process the content prior to show it on the webpage.

Some screenshots of the Django mini-blog

This is pretty spartan. Throw in some CSS if you like.

template file: ./base.html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd>
<html xmlns="http://www.w3.org/1999/xhtml">

<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<title>{% block pagetitle %}Page title{% endblock %}</title>


<link rel="stylesheet" href="" type="text/css" media="screen" />
{% block head %}

{% endblock %}

</head>
<body>
{% block body %}

{% endblock %}
</body>
</html>

template file: ./blog/index.html

{% extends "base.html" %}

{% block title %}
    A minimal blog, powered by Django
{% endblock %}

{% block body %}
<h2>Hello, world!</h2>
<ul>
<li><a href="./add">Write new post</a></li>
</ul>

{% for post in posts %}
<div class="post">
    <h2><a href="./{{ post.slug }}.html" title="{{ post.title }}">
        {{ post.title }}</a></h2>
    <div class="postmeta">
        <div class="postdate">{{ post.pub_date }}</div>
        <div class="posttags">
        Tags: 
        {% for tag in post.tags.all %}
            {{ tag.tag }},
        {% endfor %}
        </div>
        <div class="postauthor">
            By {{ post.author }}.
        </div>
    </div><!-- end postmeta -->
    <a href="./edit/{{ post.id }}">Edit post</a>
    <div class="postcontent">
    {{ post.content }}
    </div>
</div>

{% endfor %}
{% endblock %}

template file: ./blog/editpost.html

{% extends "base.html" %}

{% block title %}
        Add post
{% endblock %}

{% block body %}
<h2>Write a post</h2>
<form method="POST" action=".">
        {{ form.as_p }}

        <input type="submit" value="submit" />
</form>

{% endblock %}

models.py

# Models for django blog application

from django.db import models

class Tag(models.Model):
    tag = models.CharField(maxlength=50)  # tagname

    def __str__(self):
        return self.tag

    class Admin:
        pass

class Author(models.Model):
    name = models.CharField(maxlength=100)
    email = models.EmailField()

    def __str__(self):
        return self.name

    class Admin:
        pass

class Article(models.Model):
    title = models.CharField(maxlength=250)
    slug = models.CharField(maxlength=250)
    content = models.TextField()
    author = models.ForeignKey(Author)
    pub_date = models.DateTimeField('date published')
    mod_date = models.DateTimeField('date modified')
    tags = models.ManyToManyField(Tag)

    def __str__(self):
        return self.title

    class Admin:
        pass

url.py

# -*- coding: utf-8 -*-
from django.conf.urls.defaults import *

urlpatterns = patterns('',
    # Example:
    # (r'^djangotest/', include('djangotest.foo.urls')),

    (r'^blog/$', 'djangotest.blog.views.index'),

    #  regex for slugs.  Note that the regex matches even 
    #  .html without slug:  this gets handled in views.single
    (r'^blog/(?P<slug>((\w+|-)*))(\.html)\/?$', 'djangotest.blog.views.single'),

    # edit post
    (r'^blog/edit/(?P<post_id>\d+)/$', 'djangotest.blog.views.edit'),   

    # add new post
    (r'^blog/add/$', 'djangotest.blog.views.edit'),

    # Uncomment this for admin:
    (r'^admin/', include('django.contrib.admin.urls')),
)

views.py

# -*- coding: utf-8 -*-
# views.py

from django.http import HttpResponse, HttpResponseRedirect
from django.template import Context, loader
from django.shortcuts import render_to_response, get_list_or_404

from django import newforms as forms
from django.newforms.widgets import *

from djangotest.blog.models import *

def index(request):
    """ Display last 5 articles """
    # TODO:  make '5' not a magic number
    last_five = Article.objects.all().order_by('-pub_date')[:5]

    t = loader.get_template('blog/index.html')
    c = Context({
        'posts' : last_five,
    })

    return HttpResponse(t.render(c))


def single(request, slug):
    # handle page not found
    articles = get_list_or_404(Article, slug__exact=slug)
    return render_to_response('blog/index.html', { 'posts':articles })

def edit(request, post_id=None):

    if post_id is None:
        # no id, user is creating new post
        ArticleForm = forms.models.form_for_model(Article)
    else:
        # editing or updating post
        try:
            article = Article.objects.get(id=post_id)
        except Article.DoesNotExist:
            HttpResponseRedirect('blog/postdoesnotexist.html')

        ArticleForm = forms.models.form_for_instance(article)

    # we need to feed the new widget with the choices from the 
        # default one:  SelectMultiple

    ArticleForm.base_fields['tags'].widget = CheckboxSelectMultiple(
        choices=ArticleForm.base_fields['tags'].choices)
    ArticleForm.base_fields['author'].widget = RadioSelect(
        choices=ArticleForm.base_fields['author'].choices)

    if request.method == 'POST':
        # form has been submited (i.e., new post or old post update)
        form = ArticleForm(request.POST)
        if form.is_valid():
            form.save()
            return HttpResponseRedirect('/blog')

    else:
        # empty form
        form = ArticleForm()

    return render_to_response('blog/editpost.html', { 'form': form })

References

The following pages were of great help in understanding the newforms library better:
• The Django documentation for newforms. (Still work in progress.)
• Some examples of using a select field with static choices and hidden fields: Big nerd ranch. (qué tal nombre…)
• How to render dynamic forms using Django newforms. From the author’s blog: the newforms library works only for static forms. Forms that have a fixed number of fields. What I wanted to do, is create a page that allows you to edit multiple instances of a model at once.. Uses Javascript, no AJAX.
• How to use the model specified defaults as the default values for fields, and how to make the help_text entries available in the fields for rendering.