msgbartop
Barba, Cabello e bigode
msgbarbottom

25 set 09 Debugando no Django com winpdb

Continuando o post anterior[1], além do pdb[2] que é totalmente via linha de comando, há o winpdb[3] que possui uma interface gráfica para facilitar a depuração.

Instalá-lo é muito fácil, se você possui easy_install é só executar:

sudo easy_install winpdb

Se você não tem easy_install, mas tem apt-get:

sudo apt-get install winpdb

Se você não tem nada disso ainda dá pra baixar pelo site[3] e funciona no Windows também, mas eu não testei.

Usarei como exemplo o código criado pelo post anterior, é um projeto bem simples com apenas uma view para atestar o poder do debug.

Lembra da nossa view, ela é simples assim:

def hello(request):
    a = 2
    b = 3
    c = [1,2,3]
    c.pop()
    d = soma(3,4)
    response = HttpResponse("Hello World")
    return response

Como o winpdb possui a funcionalidade de adicionar breakpoints eu tirei aquele código de debug do pdb senão eles conflitariam entre si.

Abra o winpdb:

winpdb

A interface dele é bem simples, ficará mais clara quando estivermos executando alguma coisa.

Vá até File->Launch e na janela aberta escolha o manage.py do projeto que vamos depurar, por fim adicione runserver --noreload no comando e então clique em OK para iniciar o servidor.

O seu winpdb deve ficar parecido com a imagem abaixo, além de um terminal que será aberto pelo próprio winpdb.

winpdb executando django runserver --noreload

Antes de continuar qualquer coisa, vá até File->Open Source e na janela aberta escolha o arquivo views.py, adicione um breakpoint na linha a = 2 clicando à direita do número da linha. Tente acessar a URL que executa a view hello e volte ao winpdb, você verá algo como abaixo (a diferença é que eu já andei duas linhas no código):

winpdb na view hello

Essa imagem é bem interessante pois mostra valores das variáveis, um console escondido abaixo do código, o arquivo em que o debugger se encontra, controles de avanço do debug, etc.

Avance com Control->Next até a chamada de soma e entre com Control->Step Into, avance duas linhas e você ficará assim:

winpdb na função soma

As variáveis do escopo local mudaram, o debugger continua no views.py mas agora dentro da função soma, dê Control->Return para ir até antes da função retornar pro escopo de hello.

Com Control->Next vá até antes da linha que executa return response e vamos brincar um pouco com o console que se encontra abaixo do código-fonte:

winpdb e o console

Como você pode ver na imagem, o comando v (de eval) seguido de uma expressão retorna o valor da expressão, já o comando x (de exec) seguido de uma expressão executa a expressão informada.

Vamos fazer igual ao post anterior e verificar as propriedades de response:

winpdb e o console alterando a response

Na imagem acima, executamos um dir na variável response, exibimos seu content com v, alteramos o content com x e por fim com Control->Go visualizamos o resultado no navegador:

resultado final no navegador

Para saber de mais funcionalidades que o winpdb pode te oferecer dê uma olhada no tutorial[4] (bem completo por sinal) que se encontra na própria wiki[5] deles.

[1] – http://blog.danilocabello.com/arquivo/debugando-no-django/
[2] – http://docs.python.org/library/pdb.html
[3] – http://winpdb.org/
[4] – http://winpdb.org/cgi-bin/moin.cgi/WinpdbTutorial
[5] – http://winpdb.org/cgi-bin/moin.cgi/FrontPage

Tags: , , ,

24 set 09 Debugando no Django

Bem que você tentou, releu o código diversas vezes, escreveu um monte de prints, mas não conseguiu descobrir o que está causando aquele bug indesejado. É chegada a hora de debugar seu código, a seguir darei algumas dicas de como debugar com pdb seu projeto em Django[1].

Primeiramente, debugar um projeto em Python[2] e debugar um projeto em Django não tem muita diferença, a coisa toda é muito parecida, você só precisa do pontapé inicial para se virar dali pra frente.

Para aprender como utilizar o pdb[3] (vulgo Python Debugger) crie um novo projeto chamado djdebug, logo em seguida crie um arquivo vazio chamado views.py na própria raiz do projeto, ficando com a seguinte estrutura de arquivos:

djdebug
  - __init__.py
  - manage.py
  - settings.py
  - urls.py
  - views.py

No arquivo views.py cole o seguinte código:

from django.shortcuts import HttpResponse

def soma(a,b):
    arg1 = a
    arg2 = b
    soma = arg1 + arg2
    return soma

def hello(request):
    a = 2
    b = 3
    c = [1,2,3]
    c.pop()
    d = soma(3,4)
    response = HttpResponse("Hello World")
    return response

Como podemos ver o arquivo contém uma função soma, que não faz nada de muito complexo e uma função hello que retorna uma response com o conteúdo "Hello World".

No arquivo urls.py importe a view hello e adicione uma URL para podemos acessá-la:

from views import hello

urlpatterns = patterns('',
    ...
    (r'^hello', hello),
)

Execute o servidor de testes, navegue até http://localhost:8000/hello e verifique que está tudo funcionando:

./manage runserver

Suponha que há um bug em alguma parte da view hello e então adicione o código para possibilitar o debug:

def hello(request):
    a = 2
    import pdb
    pdb.set_trace()
    ...

Apenas para esclarecer, o import pdb importa o Python debugger, já o pdb.set_trace() serve pra colocar um breakpoint no código, há maneiras de se colocar um breakpoint no código sem alterá-lo através do próprio pdb[3].

Execute o servidor de testes mas desta vez adicione o parâmetro necessário para evitar recarregamento automático do código-fonte:

./manage runserver --noreload

Abra novamente a view hello no seu navegador, ela ficará parada e no terminal que você iniciou o servidor o pdb[3] estará parado esperando por comandos:

> /home/.../djdebug/views.py(13)hello()
-> b = 3
(Pdb)

Vamos começar, temos um comando interessante que é o l (de list, lista o código na região do debugger) que lista onde se encontra o debugger:

(Pdb) l
  8
  9  	def hello(request):
 10  	    a = 2
 11  	    import pdb
 12  	    pdb.set_trace()
 13      ->  b = 3
 14  	    c = [1,2,3]
 15  	    c.pop()
 16  	    d = soma(3,4)
 17  	    response = HttpResponse("Hello World")
 18  	    return response

É importante notar que o debugger se encontra no exato momento antes de executar a linha apontada pela seta, isto é, se executarmos p (de print, imprime a expressão passada como argumento) para inspecionarmos a variável b, ela não estará definida:

(Pdb) p a
2
(Pdb) p b
*** NameError: NameError("name 'b' is not defined",)

Vamos para próxima linha com n (de next, segue para a próxima linha):

(Pdb) n
> /home/.../djdebug/views.py(14)hello()
-> c = [1,2,3]
(Pdb) p b
3

Agora sim b já possui valor, vamos avançar até a chamada da função somar:

(Pdb) n
> /home/.../djdebug/views.py(15)hello()
-> c.pop()
(Pdb) <enter>
> /home/.../djdebug/views.py(16)hello()
-> d = soma(3,4)

A partir do primeiro n, enter executará n novamente. Como nós não sabemos se o problema da view hello é a função somar, vamos entrar na função somar com s (de step into, entra na função, ou seja, passo a dentro) e verificar se está tudo certo:

(Pdb) s
--Call--
> /home/.../djdebug/views.py(3)soma()
-> def soma(a,b):
(Pdb) l
  1  	  from django.shortcuts import HttpResponse
  2
  3     -> def soma(a,b):
  4  	      arg1 = a
  5  	      arg2 = b
  6  	      soma = arg1 + arg2
  7  	      return soma
  8
  9  	  def hello(request):
 10  	      a = 2
 11  	      import pdb

Como podemos ver o debugger se encontra na entrada da função soma, damos uma “olhada por cima” e saímos da função com up (de up, sobe uma chamada na pilha):

> /home/.../djdebug/views.py(4)soma()
-> arg1 = a
(Pdb) n
> /home/.../djdebug/views.py(5)soma()
-> arg2 = b
(Pdb) n
> /home/.../djdebug/views.py(6)soma()
-> soma = arg1 + arg2
(Pdb) u
> /home/.../djdebug/views.py(16)hello()
-> d = soma(3,4)

Como podemos ver, voltamos a view hello, vamos avançar até antes de retornar a resposta da requisição e atestar umas coisinhas:

(Pdb) n
> /home/.../djdebug/views.py(17)hello()
-> response = HttpResponse("Hello World")
(Pdb) n
> /home/.../djdebug/views.py(18)hello()
-> return response
(Pdb) dir(response)
['__class__', '__contains__', '__delattr__', '__delitem__', '__dict__', '__doc__', '__format__', '__getattribute__', '__getitem__', '__hash__', '__init__', '__iter__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__setitem__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', '_charset', '_container', '_convert_to_ascii', '_get_content', '_headers', '_is_string', '_set_content', 'close', 'content', 'cookies', 'delete_cookie', 'flush', 'get', 'has_header', 'items', 'next', 'set_cookie', 'status_code', 'tell', 'write']
(Pdb) response.content
'Hello World'
(Pdb) response.content = 'Django debugado'
(Pdb) c

Como podemos verificar, o pdb[3] fornece um shell do Python[2] você pode executar dir, verificar valores de variáveis e até mudar conteúdo de variáveis (poder e perigo andando juntos), por fim executamos c (de continue, para continuar a execução), veja o resultado no seu navegador, a mensagem "Hello World" foi trocada por "Django debugado".

Recomendo a leitura do paper “Debugging in Python”[4] para mais alguns detalhes do pdb[3]. É muito interessante saber “brincar” com o shell do Python e do Django, com essas ferramentas fica mais fácil rastrear o chato do bug.

[1] - http://www.djangoproject.com/
[2] – http://www.python.org/
[3] – http://docs.python.org/library/pdb.html
[4] – http://www.ferg.org/papers/debugging_in_python.html

Tags: , ,

31 ago 09 django-registration faciltando o cadastro de usuários

Estava procurando por uma forma de bloquear e-mails duplicados no django.contrib.auth[1], eis que encontro o projeto “plugável” django-registration[2] que não só implementa essa funcionalidade como e-mails de confirmação e a confirmação ainda expira conforme um número de dias definido nas suas settings.py.

A aplicação é muito completa, possui testes e exige o mínimo de conhecimento em Django que é saber criar templates. Ao baixar a aplicação eu pensei que iria ter que adaptar um monte de coisa para se encaixar na minha aplicação, que nada, a aplicação está no limite da plugabilidade que o Django investe.

Give a try.

[1] – http://docs.djangoproject.com/en/dev/topics/auth/#topics-auth
[2] – http://bitbucket.org/ubernostrum/django-registration/

Tags:

05 dez 08 Form Wizard: formulários passo a passo com Django

Se você já tentou implementar um formulário dividido em vários passos com certeza já encontrou problemas provavelmente em manter todos os dados ou não perder os dados digitados nos passos anteriores após validação dos dados novos.

Esqueça às dores de cabeça, na versão 1.0 do Django foi lançanda a Form Wizard, ferramenta que tem como objetivo facilitar a criação de formulários com vários passos.

Vamos a um exemplo funcional com FormWizard, para isso eu criei um projeto chamado “templo” e uma aplicação chamada “mago”, dentro da minha aplicação eu criei o arquivo forms.py com o seguinte código:

from django import forms
from django.contrib.formtools.wizard import FormWizard
from django.shortcuts import render_to_response
 
class Pessoa(forms.Form):
    nome = forms.CharField(max_length=50)
    email = forms.EmailField()
 
class Mensagem(forms.Form):
    assunto = forms.CharField(max_length=30)
    mensagem = forms.CharField(widget=forms.widgets.Textarea)
 
class Formumago(FormWizard):
    def done(self, request, form_list):
        form_data = {}
        for form in form_list:
            for field, value in form.cleaned_data.iteritems():
                form_data[field] = value
        return render_to_response('agradecimento.html', {
            'form_data': form_data,
        })

A primeira classe Pessoa é um formulário normal como todos os outros em Django com o dados da pessoa que está enviando a mensagem, a segunda classe Mensagem é outro formulário normal com os dados da mensagem, já o Formumago é um formulário especial que herda de FormWizard e tem uma função implementada done que possui o paramêtro form_list além dos comuns self e request e que é chamada após o usuário validar todos os passos.

Depois explicaremos melhor a função done vamos agora para o urls.py para fazer nossa aplicação exemplo funcionar:

from django.conf.urls.defaults import *
from templo.mago.forms import Pessoa, Mensagem, Formumago
 
urlpatterns = patterns('',
    (r'^contato/$', Formumago([Pessoa, Mensagem])),
)

No arquivo urls.py acontece a magia onde criamos um formulário com dois passos o primeiro é o formulário de Pessoa e o segundo de Mensagem. Por padrão o FormWizard procura pelo template em “forms/wizard.html” mas você pode usar outro caminho definindo uma função get_template em Formumago como explicado na documentação.

E o arquivo “forms/wizard.html” que usaremos como template:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<form action="." method="post">
<table border="0">
    {% ifequal step 1 %}
        <h1>Primeiro passo</h1>
        <h2>Seus dados pessoais</h2>
    {% endifequal %}
 
    {% ifequal step 2 %}
        <h1>Segundo e último passo</h1>
        <h2>Dados da mensagem</h2>
    {% endifequal %}
    <input name="{{ step_field }}" type="hidden" value="{{ step0 }}" />
    {{ previous_fields|safe }}
    {{ form }}</table>
<input type="submit" value="Submit" />
</form>

Como explicado na documentação o input na linha 12 e a variável previous_fields na linha 13 são necessárias para o funcionamento correto do FormWizard.

Temos também o template “agradecimento.html” mencionado no método done da classe Formumago e que exibe os dados que o usuário digitou:

<h1>Obrigado pelo contato</h1>
<h2>Sua mensagem foi enviada com os seguintes dados</h2>
<h3>Dados pessoais</h3>
<ul>
	<li>Nome: {{ form_data.nome }}</li>
	<li>Email: {{ form_data.email }}</li>
</ul>
<h3>Dados da mensagem</h3>
<ul>
	<li>Assunto: {{ form_data.assunto }}</li>
	<li>Mensagem: {{ form_data.mensagem }}</li>
</ul>

Ao executar o servidor do Django e acessarmos a página de contato, obtemos o resultado:

O primeiro passo é exibido corretamente e se preencho algo errado a validação reclama prontamente.

Ao digitar os dados corretamente o segundo passo é exibido:

Novamente a validação do formulário funciona normalmente.

Por fim o método done de Formumago pega os valores limpos e passa ao template de agradecimento apenas com o intuito de mostrar que tipo de dado vem em form_list:

def done(self, request, form_list):
        form_data = {}
        for form in form_list:
            for field, value in form.cleaned_data.iteritems():
                form_data[field] = value
        return render_to_response('agradecimento.html', {
            'form_data': form_data,
        })

O conteúdo de form_list é uma lista de objetos que herdam de forms, algo do tipo [form1, form2] e cada formulário possui seus próprios métodos, save, clean, entre outros, no caso de done a informação válida digitada no formulário é iterada formando uma novo dicionário form_data com todos os campos preenchidos à serem exibidos na página de agradecimento.

Com isso fica fácil implementar formulários com múltiplos passos apenas aproveitando os formulários que já funcionam no projeto.

Baixe o projeto exemplo.

Tags: , ,