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.

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.”

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.

A year ago I wrote a custom CheckboxSelectMultiple control for django. My application needed to display a series of checkboxes on the webpage, but the default django control did not allow iteration over each checkbox when the control was rendered in the template (as it was possible with the RadioSelect control). This finer control was necessary because I needed to insert extra HTML between each checkbox.

As of version 0.95, django has been under heavy changes, and my custom control no longer works. In particular, the old forms module is being discarded in favor of the newforms module that will become the default forms module sometime in the future. A good explanation can be found in the on-site django documentation, under newforms-migration plan.

The good news is that newforms allows access to individual items of the form fields, multiple-select fields included. The newforms documentation is still work in progress, so it took me a while to figure out how to do it… by inspecting the source code and regression tests. It seems pretty obvious now, should have asked in the django-users list.

The example code has been tested with django svn release 4812 (2007-3-23).

2007-03-27: By mistake I published an incorrect version of views.py. Code has been corrected so that now add_post saves the tag field as expected. (Post has a many-to-many relationship with Tag, so form.save() is not enough to save the form data.)

2007-04-12: The code for views.py has been corrected again. The code posted 2007-03-27 works, but as I discovered later, there is no need to create another object (p = Post(**cleandata)) to handle the many-to-many field data. form.save() takes care of everything, as expected.

2007-04-24: You may be interested in this post.

template

<ul>
{% for choice in form.base_fields.tag.choices %}
<li> ({{ choice.0 }}, {{ choice.1 }}) </li>
{% endfor %}
</ul>

models.py

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

from django.db import models

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

    def __str__(self):
        return self.tag

class Post(models.Model):
    # other fields here:
    # text = models.CharField(maxlength=255)
    # title = models.CharField(maxlength=50)
    # etc.
    tag = models.ManyToManyField(Tag)

views.py

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

from django.template import Context, loader
from django.http import HttpResponse, HttpResponseRedirect

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

from project.models import *

def add_post(request):
    postForm = forms.models.form_for_model(Post)
    if request.method == 'POST':
       form = postForm(request.POST)
        if form.is_valid():
            form.save()
            return HttpResponseRedirect("/")
    else:
         form = postForm()
         t = loader.get_template('add_post.html')
         c = Context({
               'form': form,
               })
        
         return HttpResponse(t.render(c))

views.py

This is an old version of views.py. The code works, but as I discovered later, there is no need to create another object (p = Post(**cleandata)) to handle the many-to-many field data. form.save() takes care of everything, as expected.

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

from django.template import Context, loader
from django.http import HttpResponse, HttpResponseRedirect

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

from project.models import *

def add_post(request):
    postForm = forms.models.form_for_model(Post)
    if request.method == 'POST':
        form = postForm(request.POST)
        if form.is_valid():
           cleandata = form.clean_data
           # use the form tag ids to select the Tag instances
           # related to this Post entry
           tag = Tag.objects.in_bulk(cleandata['tag'])
           # need to delete the tag ids from clean data,
           # otherwise p = Post(** cleandata) will complain that
           # tag is not a parameter of Post( )
           del cleandata['tag']

           # create an instance of Post from the form data
           p = Post(**cleandata)
           p.save()   # need to save so p gets an id.
           p.tag = tag
           p.save()

           return HttpResponseRedirect("/")
       else:
       form = postForm()

       t = loader.get_template('add_post.html')
       c = Context({
              'form': form,
        })

        return HttpResponse(t.render(c))

Resumo en este post como hacer funcionar Django en un servidor Linux con CentOS 4.4 usando Apache 2 y FastCGI. Estas cosas están dispersas en Internet, la principal finalidad del post es tenerlas juntas en algún sitio.

Por qué FastCGI y no mod_python

Es la primera pregunta que uno se hace: si mod_python funciona, para qué quieres usar FastCGI. No es porque fastcgi vuelve a estar de moda, por supuesto. El problema real es que mod_python y mod_php no se llevan bien, y de hecho en CentOS 4.4, usando mod_php, MySQL y mod_python, este último no funciona. Aquí y aquí (If you get a segmentation fault) se explican las posibles causas. Al parecer tiene que ver con el hecho de Apache usa la librería expat del sistema (y la precarga cuando se inicia el servidor de web), mientras que mod_python usa la versión de expat que fue compilada en la distribución de Python que tenga el sistema operativo. Si las dos versiones no coinciden, se produce un segmentation fault. También puede deberse a un cruce similar entre las librerías de MySQL, mod_php y mod_python, pero el resultado final es similar. En los dos casos Apache sigue corriendo y mod_python se reinicia, pero nuestro programa en Python no se ejecuta. El segfault queda registrado en el log de errores de Apache (/var/log/httpd/error_log o algún lugar cercano, dependiendo de esté instalado Apache) y el navegador queda en blanco.
Y por eso la necesidad de usar fastcgi para correr Django.

Algunas consideraciones preliminares

• El sistema en el que he hecho la instalación es un servidor con CentOs 4.4 y Python 2.3.4. (Al parecer no hay modo fácil de actualizar el Python del CentOs a 2.5 o por lo menos a 2.4 sin que se rompan muchas cosas). Estamos usando Apache2.
• Se supone que este servidor ya tiene Django instalado, y que nuestra aplicación no tiene problemas con el servidor de desarrollo que trae Django. (Esto no es un tutorial de Django… la documentación de Django explica perfectamente como instalarlo).
• Si buscamos un poco en Google, muchas páginas insisten en que si queremos instalar fastcgi y python, necesitamos instalar una librería de python llamada flup; y, si la versión de python es 2.3 o menor, también necesitamos instalar una librería llamada eunuchs. Porque a Python 2.3 le falta algo… la capacidad de escribir socket pairs, un tema que no viene al caso ahora. Bien, si lo que queremos es instalar Django, ninguna de estas dos librerías es necesaria. Django, a partir de la versión 0.95, trae su propia implementación de flup, y no necesita instalar eunuchs.

Aclarémonos dónde están las cosas

Estamos instalando django con la siguiente configuración, quizá no muy usual:

• El DocumentRoot de nuestro servidor Apache es /var/www/html.
• El directorio con el proyecto de Django es /home/django/prog.
• El directorio con los archivos .css, imágenes, y demás que necesitan las páginas web es, para el proyecto de Django, /home/django/progmedia.
• El archivo settings.py está en /home/django/prog/settings.py, que es lo normal.
• Se accede a nuestro programa a través del URL http://example.com/prog.

Instalar FastCGI

• FastCGI es un módulo de Apache que no viene con la distribución de Apache. Es necesario descargarlo del website de fastcgi: http://www.fastcgi.com.
• Las instrucciones sobre cómo compilar e instalar este módulo están muy claras en el archivo INSTALL.AP2 que viene con las fuentes de fastcgi. Pero (siempre hay un pero) lo que no dice el INSTALL.AP2 es que necesitamos además los paquetes de desarrollo de apache: httpd-devel y sus requisitos (apr-devel y apr-util-devel). Podemos decir # rpm -qa httpd* para averiguar si los headers de desarrollo están o no instalados en nuestro servidor. Si es necesario, los instalamos con yum: # yum install httpd-devel.
• Para fastcgi con CentOS es necesario usar la opción top_dir, porque por defecto fastcgi (como debe ser) trata de instalarse en /usr/local/lib en vez de en /usr/lib.

$ make top_dir=/usr/lib/httpd

• Si la compilación terminar sin errores, instalamos fastcgi con el comando

# make top_dir=/usr/lib/httpd install

• (credit where credit is due) fastcgi necesita un directorio para escribir datos de sus transacciones, pero no puede escribir a /var/log/httpd/fastcgi, la opción por defecto, aunque este directorio tenga permisos 777 y sea propiedad de apache:apache. Según dicen los mitos tiene algo que ver con el manejo de symlinks dentro de fastcgi. En el error_log de Apache aparece: [crit] (13)Permission denied: FastCGI: can't create (dynamic) server "/var/www/html/prog.fcgi": bind() failed [/var/log/httpd/fastcgi/dynamic/abcdef01020304] La solución es crear un directorio en /tmp:

# mkdir -p /tmp/fcgi/dynamic
# chown apache:apache -R /tmp/fcgi
# chmod 755 -R /tmp/fcgi

• Ahora hay que decirle a Apache que queremos usar el módulo fastcgi que acambamos de instalar. Creamos el archivo /etc/httpd/conf.d/fastcgi.conf:

LoadModule fastcgi_module modules/mod_fastcgi.so

<IfModule mod_fastcgi.c>;
    # Tenemos que decirle a fastcgi dónde puede guardar la información de sus conexiones, porque
    # no estamos usando el directorio por defecto.
        FastCgiIpcDir       /tmp/fcgi/

    # Asociamos los archivos de extensión .fcgi a fastcgi 
        AddHandler      fastcgi-script .fcgi
</IfModule>

• Recargamos la configuración de Apache y vemos en el /var/log/httpd/error_log si todo ha ido bien.

# tail -f /var/log/httpd/error_log 

(esta ventana se pude quedar abierta hasta que estemos seguros que el fastcgi funciona y bien)

En otra ventana:

# service httpd reload

RewriteEngine y ExecCGI

• Para poder usar el RewriteEngine en el directorio raíz (más abajo se explica para qué lo necesitamos), añadimos la opción FileInfo a la directiva AllowOverride del directorio raíz del servidor web.
• También queremos ejecutar programas usando fastcgi en el directorio raíz del servidor de web. (repetimos: en el directorio raíz del servidor de web, el DocumentRoot, no en el directorio en el que está nuestro proyecto Django). Para eso, modifico /etc/httpd/conf/httpd.conf

#
<Directory "/var/www/html">
# 
# (... aquí he borrado los comentarios)
#
#  Añadimos ExecCGI a las opciones

     Options Indexes FollowSymLinks IncludesNoExec <strong>ExecCGI</strong>

# (... más comentarios)
# Añado el FileInfo para que me deje usar mod_rewrite en /home/www

     AllowOverride AuthConfig <strong>FileInfo</strong>

Nuevamente recargo Apache y veo en el error_log si todo va bien.

Un puente entre Apache y Python

• Ahora necesitamos un puente (está bien, un proxy…) que permita a fastcgi comunicarse con nuestro programa en Python. Para suerte nuestra, alguien ya escribió ese puente: fcgi.py.
• Descargamos el módulo fcgi.py de internet. Ojo que si buscamos en Google hay dos resultados: uno es el módulo de Robin Dunn (el mismo de wxPython), y otro en el website de Saddi Enterprises. Este último es el que nos interesa: http://svn.saddi.com/py-lib/trunk/fcgi.py.
• Copiamos fcgi.py a la raíz del servidor web, cambiarmos propietario a apache y nos aseguramos de que apache pueda leer el archivo:

# cp fcgi.py /var/www/html
# chown apache:apache /var/www/html/fcgi.py
# chmod 755 /var/www/html/fcgi.py

• Una vez que tenemos la herramientas, ahora hay que construir el puente. Creamos el siguiente script (sacado del website de Django), que es el que, usando las funciones de fcgi.py, hace realmente de proxy entre fastcgi y nuestro proyecto Django. Lo guardo en el directorio raíz del servidor de web con el nombre prog.fcgi. (Volvemos a repetir: lo guardamos en la raíz del servidor de web, no en la raíz del directorio de nuestro proyecto).

#!/usr/bin/python

import sys, os

# Add a custom system path
sys.path.insert(0,"/home/django")

# switch to user project
os.chdir("/home/django/prog")
os.environ['DJANGO_SETTINGS_MODULE'] = "prog.settings"

from fcgi import WSGIServer
from django.core.handlers.wsgi import WSGIHandler

WSGIServer(WSGIHandler()).run()

• Idem, le cambio el propietario y permisos para que pueda ser ejecutado por Apache.

# chown apache:apache /var/www/html/prog.fcgi
# chmod 755 /var/www/html/prog.fcgi

Rewrite rules

Como dice el manual de Apache, ”Despite the tons of examples and docs, mod_rewrite is voodoo. Damned cool voodoo, but still voodoo.” — Brian Moore, bem@news.cmc.net

A continuación vamos a escribir unas reglas (”Rewrite rules”) de modo que cuando el usuario escriba el URL de nuestro programa en el navegador, Apache realmente redireccione la llamada al script prog.fcgique acabamos de escribir. Este script, a su vez, llamará al programa escrito con Django en /home/django/prog.
Explico esto en detalle porque aunque al final el resultado sea solamente dos o tres líneas en un archivo de configuración, si no entendemos qué estamos haciendo, después tendremos problemas… causados por nosotros mismos.

• Dentro del programa en Django, los distintos añadidos al URL a la derecha de sccr/ sirven para direccionar al usuario, a través del módulo urls.py, a las distintas partes de nuestro programa. Por ejemplo,

  http://example.com/prog/admin
  
  http://example.com/prog/correo
  
  

• Lo que necesitamos es que Apache pase todos esos añadidos (prog incluido) al módulo prog.fcgi, que se encargará a su vez de reenviarlo a nuestro programa de modo transparente: el programa nunca sabrá si fue llamado a través de mod_python, con el servidor de desarrollo del mismo Django, etc. (de acuerdo, probablemente sí hay forma de que lo sepa… pero a los efectos que nos interesan, no lo sabe).

  http://tierramedia.oficinas/prog.fcgi/prog/admin/
  
  http://tierramedia.oficinas/prog.fcgi/prog/correo/
  
  

• Los rewrite rules se pueden poner en muchos sitios distintos. Por ejemplo, en el archivo .htaccess en la raíz del servidor web:

RewriteEngine On
RewriteRule ^(prog\.fcgi/.*)$ - [L]
RewriteRule ^(prog/.*)$ prog.fcgi/$1 [L]

Con estas reglas, estamos diciendo dos cosas: * la primera: si el URL contiene la cadena prog.fcgi/, simplemente se pasa tal cual. La [L] quiere decir que después de esta regla no seguimos aplicando más reglas. * la segunda: si el URL contiene la cadena prog/, reescribe la cadena y todo lo que le siga insertando prog.fcgi/ por delante. Nuevamente la [L] quiere decir que después de esta regla no seguimos aplicando más reglas.

Como anteriormente hemos indicado a Apache en el archivo fastcgi.conf que toda extensión .fcgi en el directorio raíz debe procesarse con el módulo fastcgi, una vez reescrito el URL Apache ejecutará el script sccr.fcgi.

• Otra alternativa es crear un archivo /etc/httpd/conf.d/prog.conf con los rewrite rules: es más eficiente que ponerlas en .htaccess (pero por otro lado no siempre vamos a poder modificar directamente la configuración del Apache). En ese caso, tenemos que especificar cláramente para qué directorio son las reglas:

<Directory /var/www/html>
   RewriteEngine On
   RewriteRule ^(prog\.fcgi/.*)$ - [L]
   RewriteRule ^(prog/.*)$ prog.fcgi/$1 [L]
</Directory>

• Por supuesto, cada vez que cambimos la configuración necesitamos decirle a Apache que recargue los archivos de configuración: # service httpd reload.

Otros directorios de Django

• Por último, si tenemos un directorio dentro del proyecto para el media, necesitamos decirle a Apache que asocie el URL con el directorio>. Por ejemplo, http://example.com/progmedia con el directorio /home/django/progmedia. Para eso creamos o añadimos al archivo /etc/httpd/conf.d/prog.conf:

Alias /progmedia /home/django/progmedia

Y listo. Ahora deberíamos tener nuestro servidor Apache funcionando con Python, Django y FastCGI.

Note: as of Django version 0.95, this solution no longer works. But thanks to the newforms module, it is no longer necessary. Explanation of how it works can be found in this post

The problem: I have been using Django in a project for some weeks. The application needs to display a series of checkboxes on the webpage, but the HTML rendering of the formfields.CheckboxSelectMultipleField class does not offer the precise placement of each checkbox that is needed on the webpage. formfields.CheckboxSelectMultipleField is a descendant of SelectMultipleField and does not provide the ability to iterate through each of the possible choices, as formfields.RadioSelectField derived objects do:

<!-- choices is an formfields.RadioSelectField object 
      This is not possible with formfields.CheckboxSelectMultipleField derived objects.
-->
<div class="form-row">
<table><tr>
     {% for i in form.choices.field_list %}
           <td>;{{ i.field }}</td><td>{{i.name}}</td>
     {% endfor %}
     </tr>
</table>
</div>

The Solution: a custom CheckboxesMultipleSelectField based on the code from formfields.RadioSelectField.

CustomCheckboxSelectMultipleField is intended to be used in a custom Manipulator.

The code for the custom CheckboxSelectMultiple

from django.core import formfields

class CustomCheckboxSelectMultipleField(formfields.FormField):
    def __init__(self, field_name, choices=[], ul_class='', is_required=False, validator_list=[], member_name=None):
        self.field_name = field_name
        # choices is a list of (value, human-readable key) tuples because order matters
        self.choices, self.is_required = choices, is_required
        self.validator_list = [self.isValidChoice] + validator_list
        self.ul_class = ul_class
        if member_name != None:
            self.member_name = member_name

    def render(self, data):
        """
        Returns a special object that is iterable *and*
        has a default str() rendered output.

        This allows for flexible use in templates. You can just use the default
        rendering:

            {{ field_name }}

        ...which will output the radio buttons in an unordered list.
        Or, you can manually traverse each radio option for special layout:

            {% for option in field_name.field_list %}
                {{ option.field }} {{ option.label }}<br />
            {% endfor %}
        """

        class CustomCheckBoxSelectMultipleRenderer:
            def __init__(self, datalist, ul_class):
                self.datalist, self.ul_class = datalist, ul_class
            def __str__(self):
                "Default str() output for this radio field -- a <ul>"
                output = ['</ul><ul %s>' % (self.ul_class and ' class="%s"' % self.ul_class or '')]
                output.extend(['<li>%s %s</li>' % (d['field'], d['label']) for d in self.datalist])
                output.append('</ul>')
                return ''.join(output)
            def __iter__(self):
                for d in self.datalist:
                    yield d
            def __len__(self):
                return len(self.datalist)

        datalist = []
        str_data_list = map(str, data) # normalize to string
        for i, (value, display_name) in enumerate(self.choices):
            checked_html = ''
            if str(value) in str_data_list:
                checked_html = 'checked="checked"'
            datalist.append({
                'value': value, 'checked': checked_html,
                'name': display_name,
                'field': '<input type="checkbox" id="%s" name="%s" value="%s"%s/>' % \
                    (self.get_id() + '_' + str(i), self.field_name, value, checked_html),
                'label': '<label for="%s">%s</label>' % \
                    (self.get_id() + '_' + str(i), display_name),
            })

        return CustomCheckBoxSelectMultipleRenderer(datalist, self.ul_class)

    def isValidChoice(self, data, form):
        str_data = str(data)
        str_choices = [str(item[0]) for item in self.choices]
        if str_data not in str_choices:
            raise validators.ValidationError, _("Select a valid choice; '%(data)s' is not in %(choices)s.") % {'data':str_data, 'choices':str_choices}