Introdução

Jython é o responsável por tornar possível essa façanha. Segundo a wikipedia:
“Jython é uma implementação da linguagem Python que gera bytecode para máquinas Java (JVM – Java Virtual Machine). Com ela é possível fazer o desenvolvimento de aplicações híbridas que unem código em Java e Python. Esta ferramenta é muito útil também para embutir uma linguagem para criação de scripts em aplicações que requerem este tipo de funcionalidade. Também inclui um compilador que converte código fonte Python em Java bytecode, permitindo que programadores Python possam escrever classes que possam ser utilizadas por um programa Java.”
Nesse artigo vou usar o servidor tomcat por ser open source e fácil de instalar e configurar. Para fazer deploy no tomcat, é preciso antes criar um arquivo .war. Para isso vou instalar o django-jython que além de simplificar muito a criação do war facilita o acesso à banco de dados.
Informações detalhadas sobre o funcionamento e arquitetura das tecnologias utilizadas podem ser encontradas nos seus respectivos sites.

Instalação

Antes de instalar é preciso dizer que utilizar diferentes versões do trio jython + django + django-jython pode não funcionar corretamente. Uma combinação que deu certo pra mim foram jython2.5.2, django-1.2.3 e django-jython-1.2.0, que são as versões utilizadas nesse artigo.

O primeiro passo é instalar o jython. Faça o download em no site do projeto e instale no /opt.

gustavo@notebook ~$ java -jar jython_installer-2.5.2.jar

Detalhes da instalação básica podem ser lidos na wiki http://wiki.python.org/jython/InstallationInstructions.

Considerando que o virtualenv + virtualenv wrapper estão instalados, vou criar um novo ambiente virtual e instalar o django e o django-jython.

gustavo@notebook ~$ mkvirtualenv --python=/opt/jython2.5.2/bin/jython --no-site-packages env_jython
Running virtualenv with interpreter /opt/jython2.5.2/bin/jython
New jython executable in env_jython/bin/jython
Installing setuptools............................done.
virtualenvwrapper.user_scripts creating /home/gustavo/.virtualenvs/env_jython/bin/predeactivate
virtualenvwrapper.user_scripts creating /home/gustavo/.virtualenvs/env_jython/bin/postdeactivate
virtualenvwrapper.user_scripts creating /home/gustavo/.virtualenvs/env_jython/bin/preactivate
virtualenvwrapper.user_scripts creating /home/gustavo/.virtualenvs/env_jython/bin/postactivate
virtualenvwrapper.user_scripts creating /home/gustavo/.virtualenvs/env_jython/bin/get_env_details
(env_jython)gustavo@notebook ~$
(env_jython)gustavo@notebook ~$ pip install django==1.2.3, django-jython==1.2

Configuração

Django-jython implementa o pacote zxJDBC do jython que permite conectividade à banco de dados usando drivers JDBC.
Para utilizar o mysql é preciso fazer o download do mysql-connector-java-5.1.15-bin.jar, adiciona-lo no CLASSPATH e alterar o DATABASE_ENGINE no settings.py do projeto. Supondo que já exista o projeto myproject criado em /var/www/django, vou criar um diretório lib e copiar o mysql-connector para dentro dele:

(env_jython)gustavo@notebook ~$ mkdir -p /var/www/django/myproject/lib
(env_jython)gustavo@notebook ~$ cp mysql-connector-java-5.1.15-bin.jar /var/www/django/myproject/lib/
(env_jython)gustavo@notebook ~$ export CLASSPATH="$CLASSPATH:/var/www/django/myproject/lib/mysql-connector-java-5.1.15-bin.jar"

Alterando o settings.py:

DATABASES = { 
    'default': {
        'ENGINE': 'doj.backends.zxjdbc.mysql',
        'NAME': 'jython_example',
        'USER': 'username',
        'PASSWORD': 'pass',
        'HOST': 'localhost',
        'PORT': '3306',
    }
}
 
INSTALLED_APPS = (
    # outras apps aqui
    'doj',
)

Se o projeto possuir alguma classe no models.py, pode executar o syncdb para criar as tabelas no mysql:

(env_jython)gustavo@notebook myproject$ jython manage.py syncdb

Para finalizar, é preciso adicionar o projeto no PYTHONPATH. Insira o trecho abaixo no arquivo manage.py na linha 3:

import os, sys 
PROJECT_ROOT_PATH = os.path.dirname(os.path.abspath(__file__))
sys.path.append(PROJECT_ROOT_PATH)

Segundo a documentação é possível utilizar um test runner específico do django-jython que permite a saída dos resultados dos testes para um arquivo xml no mesmo formato dos gerados pelo Junit.

Deploy

Tomcat é fácil de instalar e possui uma interface web que permite fazer o upload do pacote tornando o deploy ridiculamente simples. Sua documentação é bastante completa e mostra em detalhes como instalar e configurar o ambiente.
O primeiro passo é gerar um pacote war para deploy no tomcat. Ao adicionar doj em INSTALLED_APPS no settings.py, o django-jython adiciona uma task no manage.py para criação de pacotes. Essa task usa como base o diretório war_skel que por algum motivo não está presente na instalação via pip. Então… vamos criar:

(env_jython)gustavo@notebook ~$ mkdir ~/.virtualenvs/env_jython/Lib/site-packages/doj/management/commands/war_skel
(env_jython)gustavo@notebook ~$ cd ~/.virtualenvs/env_jython/Lib/site-packages/doj/management/commands/war_skel
(env_jython)gustavo@notebook war_skel$ mkdir -p WEB-INF/lib WEB-INF/lib-python
(env_jython)gustavo@notebook war_skel$ touch application.py
(env_jython)gustavo@notebook war_skel$ touch WEB-INF/web.xml

Conteúdo do application.py:

from django.core.handlers import wsgi
import os
 
def handler(environ, start_response):
    os.putenv("DJANGO_SETTINGS_MODULE", "{{ settings.SETTINGS_MODULE }}")
    h = wsgi.WSGIHandler()
    return h(environ, start_response)

Conteúdo do web.xml:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
  <display-name>{{ project_name }}</display-name>
  <description>
   {{ project_name }} through WSGI with modjy
  </description>
  <context-param>
    <param-name>files.prefix</param-name> <!-- Needed by fileservlet -->
    <param-value></param-value>
   </context-param>
  <servlet>
    <servlet-name>modjy</servlet-name>
    <servlet-class>com.xhaus.modjy.ModjyJServlet</servlet-class>
    <init-param>
      <param-name>reload_on_mod</param-name>
      <param-value>1</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
  </servlet>
 
  <servlet>
    <servlet-name>fileservlet</servlet-name>
    <servlet-class>org.jruby.webapp.FileServlet</servlet-class>
  </servlet>
 
  {% if settings.ADMIN_MEDIA_PREFIX %}
  <servlet-mapping>
    <servlet-name>fileservlet</servlet-name>
    <url-pattern>{{ settings.ADMIN_MEDIA_PREFIX }}*</url-pattern>
  </servlet-mapping>
  {% endif %}
 
  {% if settings.MEDIA_URL %}
  <servlet-mapping>
    <servlet-name>fileservlet</servlet-name>
    <url-pattern>{{ settings.MEDIA_URL }}*</url-pattern>
  </servlet-mapping>
  {% endif %}
 
  <servlet-mapping>
    <servlet-name>modjy</servlet-name>
    <url-pattern>/*</url-pattern>
  </servlet-mapping>
</web-app>

Lembram do download do mysql-connector-java? Vamos copia-lo também para o diretório war_skel/WEB-INF/lib para ser inserido no pacote war criado pelo manage.py.

(env_jython)gustavo@notebook ~$ cp mysql-connector-java-5.1.15-bin.jar ~/.virtualenvs/env_jython/Lib/site-packages/doj/management/commands/war_skel/WEB-INF/lib/

Agora vem a parte de gerar o pacote war. Entre no diretório do projeto e execute a task war do manage.py. Mas antes certifique-se de ter executado o syncdb:

(env_jython)gustavo@notebook ~$ cd /var/www/django/myproject
(env_jython)gustavo@notebook myproject$ jython manage.py war

Se tudo deu certo, foi gerado um pacote war no diretório de um nível acima do projeto (/var/www/myproject.war).
Com o tomcat rodando, acesse o endereço http://localhost:8080/manager/html, clique em “Select WAR file to upload” e depois no botão deploy.

Conclusão

Embora o jython não tenha um desenvolvimento muito acelerado, vimos que já é possível utilizar um projeto django com acesso à banco de dados com muita facilidade e poucas alterações.
Em termos de desempenho não tenho qualquer informação que possa compartilhar com vocês, e caso alguém tenha algum caso de sucesso (ou mesmo insucesso) seria legal compartilhar com a comunidade.
Lembrando que o django-jython 1.2 possui backend estável apenas para os bancos de dados oracle, mysql e postgresql.

Links

http://www.jython.org/downloads.html/
http://packages.python.org/django-jython/quickstart.html
http://tomcat.apache.org/

Introdução

Nginx foi desenvolvido inicialmente em 2002 por Igor Sysoev para servir um site russo chamado Rambler que tinha milhares de requisições por dia. Entre suas características estão o baixo consumo de cpu e memória (pois usa um processo por core para gerenciar varias conexões) e o formato dos arquivos de configuração que são mais simples de entender e modificar do que os do apache.
Entre os grandes sites que o utilizam, podemos destacar o wordpress e sourceforge.

VirtualEnv é um software que permite criar um ambiente python único e exclusivo para cada projeto. Não entrarei em detalhes sobre seu funcionamento então recomendo uma lida no artigo Gerenciando Ambientes Virtuais que explica melhor sobre o assunto.

Instalação

$ sudo apt-get install nginx
$ sudo pip install virtualenv, virtualenvwrapper

Configuração

Por padrão o arquivo de configuração é o /etc/nginx/nginx.conf. Vamos modifica-lo e deixar como abaixo:

user www-data;
worker_processes 2;
 
error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;
 
http {
    include     /etc/nginx/mime.types;
    access_log  /var/log/nginx/access.log;
    sendfile        on;
    keepalive_timeout  65;
    tcp_nodelay        on;
    gzip  on;
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";
 
    server {
        server_name project-1-0;
        listen 80;
 
        location /media {
            autoindex on;
            alias /var/www/project_1_0/media;
            expires 31d;
        }
 
        location /admin_media {
            autoindex on;
            alias /var/www/project_1_0/media/admin;
            expires 31d;
        }
 
        location / { 
            root /var/www/project_1_0;
            fastcgi_pass 127.0.0.2:8000;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $fastcgi_script_name;
            fastcgi_param REQUEST_METHOD $request_method;
            fastcgi_param QUERY_STRING $query_string;
            fastcgi_param CONTENT_TYPE $content_type;
            fastcgi_param CONTENT_LENGTH $content_length;
            fastcgi_param SERVER_PORT $server_port;
            fastcgi_param SERVER_NAME $server_name;
            fastcgi_param SERVER_PROTOCOL $server_protocol;
        }   
    }
 
    server {
        server_name project-1-3;
        listen 80; 
 
        location /media {
            autoindex on; 
            alias /var/www/project_1_3/media;
            expires 31d;
        }
 
        location /admin_media {
            autoindex on; 
            alias /var/www/project_1_3/media/admin;
            expires 31d;
        }
 
        location / { 
            root /var/www/project_1_3;
            fastcgi_pass 127.0.0.3:9000;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $fastcgi_script_name;
            fastcgi_param REQUEST_METHOD $request_method;
            fastcgi_param QUERY_STRING $query_string;
            fastcgi_param CONTENT_TYPE $content_type;
            fastcgi_param CONTENT_LENGTH $content_length;
            fastcgi_param SERVER_PORT $server_port;
            fastcgi_param SERVER_NAME $server_name;
            fastcgi_param SERVER_PROTOCOL $server_protocol;
       }
    }
}

Pode-se dizer que o arquivo de configuração do nginx é uma lista de diretivas organizadas em uma estrutura lógica. Nginx é modular e cada módulo possui um conjunto específico de diretivas. Na configuração acima, todas as diretivas fazem parte do core do nginx, exceto as diretivas fastcgi que fazem parte do módulo FastCGI. Esse módulo é incluído por padrão na compilação do nginx, sendo assim não é preciso ativa-lo.
Nginx trabalha com um sistema de blocos. Um configuração mínima requer os principais blocos: http, server e location.

O bloco http é responsável por tratar requisições desse tipo. Ele pode conter um ou mais blocos server que contém configurações para um virtual host. Cada server pode ter um ou mais blocos location. Esse por sua vez possui configurações para um determinado url pattern.
Na configuração acima foram criados dois blocos server (um para cada projeto) e cada um possui três blocos location contendo configurações para arquivos estáticos e para os projetos em django.

Algumas diretivas podem ser colocadas na raiz do arquivo, fora dos blocos. Diretivas assim são chamadas de diretivas globais e afetam as demais configurações.
Sobre algumas diretivas:

user www-data
Define o usuário do nginx. Coloquei o mesmo usado pelo apache mas nada impede de usar outro. Apenas lembre-se de atribuir as devidas permissões nos diretórios dos projetos para esse user.

worker_processes 2
Define o número de processos executados por core da CPU. No meu caso, uso uma CPU Core 2 Duo.

error_log /var/log/nginx/error.log
Caminho para o arquivo de log de erros.

pid /var/run/nginx.pid
Caminho para o arquivo contendo o PID do nginx.

include /etc/nginx/mime.types
Similar à função include usada em algumas linguagens. Insere o conteúdo do arquivo externo no trecho indicado.

access_log /var/log/nginx/access.log
Caminho para o arquivo de log de acessos.

sendfile on
Se habilitado, nginx usa sendfile kernel call para gerenciar transmissão de arquivos. Se desabilitado, ele próprio gerencia a transmissão. Dependendo da localização física do arquivo, isso pode afetar a performance.

keepalive_timeout 65
Tempo de espera do servidor para fechar conexões keep-alive.

tcp_nodelay on
Habilita ou não a opção TCP_NODELAY para conexões keep-alive. TCP_NODELAY é usado para um único propósito; desabilitar o algoritmo de buffer Nagle. Deve ser habilitado apenas para aplicações que enviam frequentemente requests sem necessidade de obter um response imediato.

gzip on
Habilita compressão gzip.

gzip_disable "MSIE [1-6]\.(?!.*SV1)"
Desabilita a compressão gzip para requests cujo o User-Agent no cabeçalho http combine com a expressão regular. Nesse caso, desabilita para o internet explorer.

server_name project-1-0
Associa um ou mais hostnames ao bloco server. O nginx verifica o Host no cabeçalho do request e seleciona o primeiro bloco que combina.

listen 80
Escuta na porta 80 (padrão http).

autoindex on
Exibe os arquivos do diretório.

alias /var/www/project_1_0/media
Define a location /media como um atalho para o diretório media do projeto.

expires 31d
Define o tempo de expiração do conteúdo. Nesse caso, 31 dias.

root /var/www/project_1_0
Caminho do projeto.

fastcgi_pass 127.0.0.2:8000
Endereço e porta do servidor web usado pelo django. Ex.: python manage.py runfcgi host=127.0.0.2 port=8000 pidfile=/var/run/project_1_0.pid

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name
fastcgi_param PATH_INFO $fastcgi_script_name
fastcgi_param REQUEST_METHOD $request_method
fastcgi_param QUERY_STRING $query_string
fastcgi_param CONTENT_TYPE $content_type
fastcgi_param CONTENT_LENGTH $content_length
fastcgi_param SERVER_PORT $server_port
fastcgi_param SERVER_NAME $server_name
fastcgi_param SERVER_PROTOCOL $server_protocol
Repassa os parâmetros do request recebido pelo nginx para o servidor fastcgi.

Para finalizar a configuração, vamos editar o /etc/hosts e adicionar dois virtual hosts referentes aos projetos.

$ sudo /etc/hosts
 
127.0.0.2   project-1-0.localdomain project-1-0
127.0.0.3   project-1-3.localdomain project-1-3

Notem que estou utilizando dois IPs de loopback, ou seja, visível somente na máquina local.

Criando os Projetos

Agora vem a parte mais fácil. Vamos criar dois ambientes virtuais (env-1.0 e env-1.3) e instalar o django-1.0 em um e o django-1.3 no outro.
Dentro de cada ambiente vou criar um projeto que vai exibir a versão do django em uso.
O único pacote python obrigatório a ser instalado é o flup, que é uma coleção de módulos WSGI.
Vou usar o virtualenv + virtualenv wrapper e como já havia dito não entrarei em detalhes sobre essas ferramentas.

Ambiente 1.0

Criando o ambiente env-1.0 e o projeto dentro do diretório /var/www:

gustavo@notebook www$ mkvirtualenv --no-site-packages env-1.0
(env-1.0)gustavo@notebook www$ pip install django==1.0, flup
(env-1.0)gustavo@notebook www$ django-admin startproject project_1_0

Modificando o arquivo project_1_0/urls.py para exibir a versão do django na tela:

from django.conf.urls.defaults import *
from django.http import HttpResponse
import django
 
urlpatterns = patterns('',
    (r'^version/$', lambda request:HttpResponse(django.VERSION)),
)

Executando o servidor fastcgi:

(env-1.0)gustavo@notebook project_1_0$ python manage.py runfcgi host=127.0.0.2 port=8000 pidfile=/tmp/project_1_0.pid

Agora basta testar. Abra o navegador e digite http://project-1-0/. Se tudo deu certo então será exibido na tela a versão do Django, no caso “10final”.

Ambiente 1.3

Criando o ambiente env-1.3 e o projeto:

gustavo@notebook www$ mkvirtualenv --no-site-packages env-1.3
(env-1.3)gustavo@notebook www$ pip install django==1.3, flup
(env-1.3)gustavo@notebook www$ django-admin startproject project_1_3

Modificando o arquivo project_1_3/urls.py para exibir a versão do django na tela:

from django.conf.urls.defaults import patterns, include, url 
from django.http import HttpResponse
import django
 
urlpatterns = patterns('',
    (r'^version/$', lambda request:HttpResponse(django.VERSION)),
)

Executando o servidor fastcgi:

(env-1.3)gustavo@notebook project_1_3$ python manage.py runfcgi host=127.0.0.3 port=9000 pidfile=/tmp/project_1_3.pid

Abra o navegador e digite http://project-1-3/. Deve ser exibido na tela a versão do Django, “130final0″.

Conclusão

Esse artigo mostrou uma forma simplista de servir dois projetos usando versões diferentes do django no nginx. Na configuração foram criados blocos location para servir arquivos estáticos como /media e /admin_media porém nos projetos não me aprofundei em alterar o settings.py para isso.

O Nginx possui a diretiva include que permite inserir trechos de configuração localizados em outros arquivos no arquivo de configuração principal. Sendo assim, como boa prática, é indicado colocar a configuração de cada projeto em arquivos separados. No ubuntu 10.10 o diretório /etc/nginx possui dois sub-diretórios, sites-available e sites-enabled, similar ao apache2. A idéia é colocar os arquivos de configuração referentes a cada projeto dentro de sites-available e criar um link simbólico em sites-enabled para habilitar seu uso.
Quem quiser conhecer melhor esse fantástico servidor web, recomendo a leitura do livro Nginx HTTP Server, que inclusive serviu como base para esse artigo.

Links

Nginx Project Page
Planet Nginx
Nginx HTTP Server Book

Essa semana foi lançado o site tipsforlinux.com, meu projeto pessoal open source desenvolvido em Django. O site é um blog, cuja função é ser um repositório de dicas e truques sobre GNU/Linux. Possui um visual simples e leve possibilitando uma navegação agradável até mesmo nos navegadores em modo texto. O site não chega a ser uma idéia inovadora, na verdade ele surgiu da vontade de programar novamente em Django.
O projeto utiliza as apps django-tagging, django-pagination, django-socialauth, django-contact-form, python-twitter, comments e sitemaps e o codigo está disponibilizado no github.

Site:
http://tipsforlinux.com

Código:
http://github.com/gustavohenrique/TipsForLinux

Django é o framework ideal para os que buscam agilidade e simplicidade. Um dos recursos que mais gosto é o Admin, uma poderosa interface para produzir conteúdo. Simples de usar, bastante customizável e com um visual agradável, bastante útil durante a fase de desenvolvimento e ideal para pequenos projetos com ausência de um designer na equipe. Outras caracteristicas interessantes são:

• API para autenticação de usuários com suporte à grupos e níveis de acesso, que permite a criação de permissões personalizadas para cada página, classe ou método;
• Sistema de cache que torna mais rápido o carregamento das páginas e o acesso ao banco de dados;
• Sistema de templates utilizando HTML, com suporte a herança e Template Tags – uma linguagem de templates para manipulação de conteúdo dinamicamente. É possível criar suas próprias com código Python e utiliza-las em qualquer parte do projeto;
• Trabalhar com formulários e extremamente simples e há diversos tipos de validações disponíveis como por exemplo e-mail, cpf e endereço IP;
• ORM compatível com os bancos de dados mais utilizados no mercado;
• Paginação é uma tarefa trivial;
• Incrível suporte à internacionalização;
• É multiplataforma;
• Documentação bem completa e de fácil entendimento;
• Comunidade altamente ativa.

Por utilizar Python, é compatível com uma grande variedade de bibliotecas para trabalhar com xml, json, webservices, restful, graficos, relatorios, imagens e etc. Sem dúvida uma ótima escolha para quem procura agilidade com produtividade.

Essa foi minha opinião expressada no debate Django vs. Ruby on Rails, matéria da revista TiDigital (edição 16 de junho/2010).

Pisa é um conversor de HTML/XHTML/CSS para PDF, escrito em Python e baseado nas bibliotecas Reportlab, PyPDF, TechGame Networks CSS e HTML5lib. Seu foco principal não é gerar páginas perfeitas para impressão, mas utilizar HTML e CSS para gerar PDFs dentro de aplicações.
A instalação pode ser feita através do código no site do projeto ou pelo comando easy_install pisa.

Crie um arquivo chamado report.py dentro do diretório do projeto contendo o código abaixo:

# -*- coding: utf-8 -*-
from django import http
from django.template.loader import get_template
from django.template import Context
import ho.pisa as pisa
import cStringIO as StringIO
import cgi, os
 
 
def fetch_resources(uri, rel):
    path = '/path/para/diretorio/contendo/imagens/a/serem/exibidas'
    return path
 
def write_to_pdf(template_src, context_dict, filename):
    template = get_template(template_src)
    context = Context(context_dict)
    html  = template.render(context)
    result = StringIO.StringIO()
    pdf = pisa.pisaDocument(StringIO.StringIO(html.encode("UTF-8")), result, link_callback=fetch_resources)
    if not pdf.err:
        response = http.HttpResponse(mimetype='application/pdf')
        response['Content-Disposition'] = 'attachment; filename=%s.pdf' % filename
        response.write(result.getvalue())
        return response
    return http.HttpResponse('Problema ao gerar PDF: %s' % cgi.escape(html))

E agora, dentro de uma view, é preciso importar o arquivo report.py e chamar a função write_to_pdf para fazer a conversão:

# views.py
from report import write_to_pdf
 
def listar_clientes_cadastrados(request):
    clientes = Cliente.objects.all()
    return write_to_pdf('relatorio.html', {'clientes': clientes}, 'nome_do_arquivo_pdf')

A função write_to_pdf recebe como parâmetro o nome do arquivo HTML que será convertido, as variáveis que serão tratadas dentro desse arquivo e o nome que o arquivo PDF sem a extensão. Retorna o download do arquivo PDF.

Conforme citado no início do post, a conversão não é perfeita. Por exemplo, às vezes uma tabela apresenta mínimas deformações, não fica igual como na versão HTML. Apesar disso Pisa é uma ótima solução que muitas vezes ajuda bastante e, como puderam ver, é muito fácil de usar.

Um formulário dinâmico é aquele que o usuário pode definir quais campos vão existir. O programador não precisa criar código para cada formulário.
Imagine um sistema que necessite de diversos tipos de formulários. Tarefa no mínimo entediante para o responsável pela manutenção. E se o usuário puder criar e modificar um formulário por uma interface gráfica fácil de usar? Seria muito bom para o programador!
O segredo desse dinamismo é o uso de metaclasses, que são classes cujas instâncias também são classes.
O truque é criar em tempo de execução uma metaclasse da classe forms.Form. Atributos dos campos como label, tipo, max length etc, podem ficar armazenados no banco de dados. Os valores dos campos podem ficar em outra tabela com uma referência de chave estrangeira. Usando o ORM do Django é muito simples, e de quebra já ganha uma interface gráfica para administrar tudo (admin).
Sendo assim, o usuário poderia montar os campos do formulário definindo um label, tipo de campo, se é obrigatório ou não, valor padrão… e essas informações ficarão no armazenadas no BD. Fica fácil criar um código para pegar essas informações, criar uma nova classe Form em tempo de execução, instância-la e renderizar no template.

Exemplo:

# views.py
 
from django.views.generic.simple import direct_to_template
from django.forms import forms, fields
 
def montar_formulario_dinamico(request):
    campos_dinamicos = {
        'nome': fields.CharField(max_length=100, required=True, label='Nome', initial='Gustavo'),
        'idade': fields.IntegerField(label='Idade', min_value=0),
        'email': fields.EmailField(max_length=200, required=False, label='E-mail')
    }
 
    FormDinamico = type('', (forms.Form,), campos_dinamicos)
    form = FormDinamico()
 
    return direct_to_template(request, 'formulario.html', extra_context={'formulario': form})

Fica a dica!

Instalação

Há diversas maneiras de se instalar um sistema feito em django. Vou mostrar como fazer o deploy usando Apache2 com o módulo mod_wsgi.
O ambiente completo usa Apache2, sqlite3, python-2.6 e Django-1.1.

root@localhost# apt-get install apache2 libapache2-mod-wsgi sqlite3 python-pysqlite2 python-django

O diretório web padrão do Apache no Ubuntu é o /var/www. Vamos manter assim. Faça o download do Bandcontrol pelo site github.com (no site, clique no botão Download Source), descompacte no /var/www, renomeie o diretório para bandcontrol e altere o dono/grupo de acordo com o usuário do apache.

root@localhost: /var/www# tar zxvf gustavohenrique-bandcontrol-XXXXXX.tar.gz
root@localhost: /var/www# mv gustavohenrique-bandcontrol-XXXXXX bandcontrol
root@localhost: /var/www# chown www-data.www-data -Rf bandcontrol

Os shell scripts usam o Iptables para firewall e TC para controle de banda. É necessário permissão de super usuário para executar esses comandos. Vamos configurar o sudo para que o usuário do Apache possa executar tais comandos como root.

root@localhost: /var/www# visudo

Adicione essas linhas no arquivo /etc/sudoers:

# No Ubuntu o iptables e o tc estao dentro do /sbin
Cmd_Alias BANDCONTROL = /sbin/iptables, /sbin/tc
www-data  ALL = (ALL) NOPASSWD: BANDCONTROL

Configuracao do Apache

Configure um virtualhost no apache criando o arquivo /etc/apache2/sites-enabled/bandcontrol contendo:

WSGIRestrictStdout Off
NameVirtualHost bandcontrol
 
        ServerAdmin webmaster@localhost
        LimitInternalRecursion 1000
        ServerName bandcontrol
 
 
                Options ExecCGI FollowSymLinks MultiViews
                AllowOverride FileInfo
                MultiviewsMatch Handlers
                Order deny,allow
                Allow from all
 
 
        ErrorLog /var/log/apache2/bandcontrol_error.log
        CustomLog /var/log/apache2/bandcontrol_access.log combined
 
        WSGIScriptAlias /     "/var/www/bandcontrol/config.wsgi"
 
        Alias /admin_media/ "/usr/lib/pymodules/python2.6/django/contrib/admin/media/"
        Alias /media/           "/var/www/bandcontrol/media/"

Edite o /etc/hosts e adicione:

127.0.0.2     bandcontrol

Configuracao do Bandcontrol

Altere o arquivo /var/www/bandcontrol/config.wsgi ajustando o diretório de instalação do Django. O padrão do Ubuntu é /usr/lib/pymodules/python2.6/django. Nesse arquivo também é configurado o diretório do bandcontrol:

import os, sys
PROJECT_ROOT_PATH = os.path.dirname(os.path.abspath(__file__))
sys.path.insert(0, PROJECT_ROOT_PATH)
sys.path.append('/usr/lib/pymodules/python2.6/django/')
sys.path.append('/var/www')
os.environ['DJANGO_SETTINGS_MODULE']='settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
 
import bandcontrol.monitor
bandcontrol.monitor.start(interval=1.0)

No arquivo /var/www/bandcontrol/settings.py é possível fazer mais alterações.
Para definir as interfaces de rede e classe IP utilizada na rede, edite os arquivos /var/www/bandcontrol/scripts/CONFIG e /var/www/bandcontrol/scripts/firewall.

Por padrão é utilizado o banco de dados sqlite3. Você pode escolher usar o MySQL ou PostgreSQL editando o arquivo /var/www/bandcontrol/settings.py.
Para criar o BD, entre no diretório do bandcontrol e execute o comando manage.py syncdb. Digite yes para confirmar a criação do super usuário. Forneça um login, e-mail e senha:

root@localhost: /var/www/bandcontrol# python manage.py syncdb
Creating table auth_permission
Creating table auth_group
Creating table auth_user
Creating table auth_message
Creating table django_content_type
Creating table django_session
Creating table django_site
Creating table django_admin_log
Creating table rede_plano
Creating table rede_pontorede
 
You just installed Django's auth system, which means you don't have any superusers defined.
Would you like to create one now? (yes/no): yes
Username (Leave blank to use 'root'): gustavo
E-mail address: eu@gustavohenrique.net
Password:
Password (again):
Superuser created successfully.
Installing index for auth.Permission model
Installing index for auth.Message model
Installing index for admin.LogEntry model
Installing index for rede.PontoRede model

Reinicie o Apache para que as alterações tenham efeito.

Utilização

Abra o browser e acesse http://bandcontrol/.
Reparem que no campo de endereço da URL e os nomes de usuário utilizados não condizem com o que foi exemplificado nesse artigo. Bom... estou com preguiça para alterar as imagens, então vamos desconsiderar esse "bug".

Entre com o login e senha criados no passo anterior.

Tela inicial do sistema.

Clique em Planos e vamos criar alguns.

Volte à tela inicial, clique em Pontos de Rede. No menu superior há opção para executar o firewall, parar o controle de banda e exibir os IPs conectados ao servidor. Sempre que fizer alguma alteração no sistema deve executar o firewall para ativar as mudanças.

Em exibir IPs conectados, para adicionar um IP no sistema forneça uma descrição única, escolha o plano e clique em [+].

O bandcontrol permite criar outros usuários com acesso ao sistema. Trabalha com permissões e grupos. Cortesia do Django \o/

Conclusão

Bandcontrol foi uma daquelas coisas "pra ontem". Foi feito em uma tarde de terça-feira. Tal velocidade se deve ao framework Django.
Esse artigo foi escrito um pouco de cada vez, por isso há grandes chances de algo sair errado. Há muito material disponível na web sobre deploy de projetos em Django. Em caso de dúvidas estarei disposto a ajudar.

Tela do jqDjangoGrid

jqDjangoGrid é um plugin para JQuery com uma aplicação plugável do Django para criar um datagrid.
Fácil de instalar e customizar, possui ordenação de resultados e pesquisa usando ajax.
Atualmente não suporta recurso de inserir ou alterar registros diretamente no datagrid, mas possui um método genérico para remoção de registros e outro que retorna a PK (Primary Key) do objeto selecionado.

INTRODUÇÃO

Neste artigo mostrarei como é fácil instalar e usar o jqDjangoGrid. Todos os códigos estão comentados para ajudar à quem precisar fazer alguma modificação, por isso eu aconselho a usar algum compactador de código javascript se for usar em ambiente de produção.
O tema padrão é o mesmo utilizado em um artigo anterior sobre datagrid com django, usando tons cinzas e azul. É fácil criar novos temas, bastar alterar o arquivo CSS e substituir as imagens.

Estou disponibilizando 2 arquivos para download, um contendo apenas o jqDjangoGrid e o outro contendo uma aplicação de exemplo (Um cadastro de bookmarks). É necessária a biblioteca JQuery para funcionar. Os pacotes estão com a versão 1.3.2 dessa biblioteca.

Download:

Baixe a última versão com um exemplo no site github.com.
Código no GitHub

INSTALAÇÃO E UTILIZAÇÃO

Instalação:

1. Descompacte o pacote jqdjangogrid.tar.gz;
2. copie o diretório jqdjangogrid, que é a app em django, para o diretório do seu projeto;
3. Copie os arquivos .js para o diretório de arquivos javascript do seu projeto (dento do MEDIA_ROOT);
4. Copie o diretório themes para o diretório de arquivos CSS do seu projeto (também dentro do MEDIA_ROOT)

Utilização:

Insira jqdjangogrid em INSTALLED_APPS localizada no settings.py e depois crie uma regra no urls.py.

INSTALLED_APPS = (
    # outras apps instaladas aqui
    'jqdjangogrid',
)

urlpatterns = patterns('',
    # suas outras regras aqui
    (r'^jqdjangogrid/', include('jqdjangogrid.urls')),
)

Inclua uma referência para os arquivos jqdjangogrid.css, jquery.js e jqdjangogrid.js dentro do template HTML principal. Ex.:

<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<link rel="StyleSheet" type="text/css" href="/path_to_your_css/css/themes/default/jqdjangogrid.css">
<script language="JavaScript" type="text/javascript" src="/path_to_your_js/jquery.js"></script>
<script language="JavaScript" type="text/javascript" src="/path_to_your_js/jqdjangogrid.js"></script>
...

Crie um div qualquer para servir como contâiner para o datagrid.

<div id="mydatagrid"></div>

Agora é só criar um objeto datagrid passando as configurações. Abaixo um exemplo com as configurações básicas criado no momento em que a página é carregada:

<!-- dentro da tag head -->
<script type="text/javascript">
$(document).ready(function() {
    $('#mydatagrid').datagrid({
        'appLabel': 'myapp',
        'modelName': 'MyClassName',
        'cols': {
            "pk": {"label": "", "width":"10px"},
            "field1": {"label": "Campo 1", "width": "100px"},
            "field2": {"label": "Campo 2", "width": "300px"},
        },
    });
});
</script>

Assim, ao carregar a página, será criado um datagrid contendo 3 colunas. Quando o nome da coluna for pk, vai aparecer um radio input cujo valor é a chave primária. Os outros atributos do campo são largura e label que vai aparecer no datagrid.

Conheça outros recursos na próxima página.

INTRODUÇÃO

O funcionamento da integração com o PagSeguro é simples:

1. Preenchimento do form com dados do pedido:
   Uma view do site renderiza um template contendo um form com campos ocultos (input type=”hidden”) preenchidos com dados sobre o pedido.
2. Envio dos dados à URL do pagseguro:
   O form é submetido via POST para a URL do PagSeguro que recebe os dados do pedido e exibe a tela de escolha da forma de pagamento.
3. Envio dos dados sobre a transação:
   Após o comprador escolher a forma de pagamento, o robô do PagSeguro envia em segundo plano um POST para a URL de retorno configurada pelo vendedor no site do PagSeguro. Em seguida redireciona o comprador para essa mesma URL de retorno.

A parte mais complicada é no passo 3, onde ocorre a comunicação em segundo plano (invisível ao usuário, não aparece no browser).
O robô do PagSeguro envia um POST para a URL de retorno definida pelo vendedor. Então é preciso verificar nessa URL se houve alguma requisição via POST. Então o método da view envia uma requisição ao PagSeguro, também em segundo plano, contendo os mesmos dados obtidos via POST e um código único (token) definido no painel de configuração da conta no site do PagSeguro. Após verificado a autenticidade da transação, os dados são armazenados no banco de dados para que o cliente possa acompanhar o status do pedido diretamente no seu site.

MÃO NA MASSA

Não será abordado quais campos e tipos de dados que devem ser enviados ao PagSeguro. Essas informações estão bem documentadas no site do mesmo.
No momento apenas será descrito como verificar a autenticidade da transação.

Vamos criar uma app chamada utils. Dentro do diretório dessa app, criamos o arquivo pagamentolib.py.

$ python manage.py startapp utils
$ vim utils/pagamentolib.py

Eis o código do pagamentolib.py:

# -*- coding: utf-8 -*-
 
import sys
import urllib2, urllib
from django.http import HttpResponse
 
 
class Pagamento(object):
 
    def _conectar(self, url, params):
        query_str = urllib.urlencode(params)
        req = urllib2.Request(url, query_str)
        f = urllib2.urlopen(req)
        conteudo = f.read()
        f.close()
        return conteudo
 
    def _enviar(self, url, params):
        retorno = self._conectar(url, params)
        if retorno.lower() == 'verificado':
            return True
        else:
            return False
 
 
class PagSeguro(Pagamento):
    def processar(self, token, params, url='https://pagseguro.uol.com.br/Security/NPI/Default.aspx'):
        if not params:
            return False
        else:
            lista = []
            for key in params.keys():
                lista.append((key,params[key]))
            lista.append(('Comando', 'validar'))
            lista.append(('Token', token))
 
            return self._enviar(url, lista)

Como exemplo, nossa URL de retorno é http://www.seusite.com/concluir/, que chama o método concluir contido na app carrinho

# -*- coding: utf-8 -*-
 
from django.views.generic.simple import direct_to_template
from meuprojeto.utils.pagamentolib import PagSeguro
 
def concluir(request):
    """
    Descricao:
    Armazena os dados do pedido e exibe a tela de pedido concluido.
    Verifica se o robo do PagSeguro enviou os dados do pedido via POST, e
    então armazena no banco de dados.
    Por fim, exibe a tela de pedido concluido com sucesso.
    """
 
    if request.method == 'POST':
        # token gerado no painel de controle do PagSeguro
        token = '12345699CA2AAAF4599EA697BB2F7FFF'
        p = PagSeguro()
        retorno = p.processar(token, request.POST)
 
        if retorno == True:
            try:
                # Cadastra os dados recebidos no banco de dados.
                # Utilize o request.POST.get('nomedocampo') para obter os valores
            except:
                pass
            return HttpResponse('Ok')
        else:
            return HttpResponse('Error')
 
    else:
        # Carrega tela contendo a mensagem de compra realizada
        return direct_to_template(request,'carrinho/concluir.html')

SERVIDOR DE TESTE

No site da Visie (empresa parceira do PagSeguro) está disponível para download uma aplicação feita em python que simula o servidor do PagSeguro. Com esse servidor de testes é possível verificar se a integração está enviando e recebendo os dados corretamente. É um servidor semelhante ao que acompanha o Django.

1. Faça o download em: http://visie.com.br/pagseguro/pagseguro_testserver_v0.21.zip e Descompacte em qualquer diretório.
2. Entre no diretório pagseguroMockup, edite o arquivo settings.py e altere o valor da variável retornourl para sua URL de retorno em ambiente de teste. Altere também dentro do arquivo pagseguro.py na linha 77 onde está ‘ProdId’ por ‘ProdID’.
3. Insira a linha 127.0.0.1 pagseguro.uol.com.br pagseguro no arquivo /etc/hosts. Agora basta executar o comando sudo python PagSeguroServer.py para iniciar o servidor de testes. Ctrl + C para sair.

CONCLUSÃO

O que foi mostrado nesse artigo também serve com base para comunicação com webservices de outros serviços de pagamento on-line. Eu aconselho a quem estiver pensando em desenvolver um e-commerce que utilize algum serviço desse tipo a não se prender em apenas um. Deixem pré-configurado uma segunda alternativa caso venha a ter problemas com a primeira.
Fiquei decepcionado quando não encontrei exemplos em Python no site do PagSeguro. Na minha opinião, se uma empresa disponibiliza um webservice e ganha sobre isso, deveria investir melhor na documentação e principalmente no suporte.