Rails 4 - has_and_belongs_to_many migration

Agora com o rails 4 existe um novo helper para gerar tabelas de ligação.

O "create_join_table", conforme encontrado na documentação.

Segue aqui um trecho da documentação:

create_join_table(:assemblies, :parts)

Ou ainda, criando já os índices:

create_join_table :products, :categories do |t| t.index :product_id t.index :category_id end

Huhu!

Django 1.4 - FormView

Hoje vamos descrever o uso de um FormView:

FormView

Uma FormView é responsável por renderizar o Form associado à um template, validar-lo após ser submetido e redirecionar o aplicativo para outra URL.

Para utilizar o FormView, basta realizar as seguinte implementação:

#urls.py
from django.conf import settings
from django.conf.urls.defaults import patterns, include, url
from django.views.generic import FormView, TemplateView
from home.forms import FormWidgets

urlpatterns = patterns('',
                       
    url(r"^formview/$", FormView.as_view(form_class = FormWidgets, \
                                        template_name = "render_form.html", \
                                        success_url = "success"), \
                                        name="custom_widgets.form"),
                       
    url(r"^formview/success/$", TemplateView.as_view(template_name = "success.html")),
)

A FormView instancia uma variável chamada form que armazena o Form indicado pelo atributo form_class. Abaixo demonstro um Template simples que pode ser utilizado em conjunto com uma FormView.

<form method="post"/>
{% csrf_token %}
    {{ form.as_p }}
    <input type="submit" value="Submit" />
</form>

Esta View além do redirecionamento não realiza nenhuma ação após o formulário ser submetido. O que, a primeira vista pode parecer inútil, mas não é.

Um exemplo de uso seria utilizá-la para validar o Form através de uma requisição AJAX e utilizar o redirecionamento como confirmação no Javascript.

Por hoje é isso!

Django 1.4 - TemplateView

Uma generic view disponível no Django à partir da versão 1.4 é a TemplateView, esta class-based view é responsável somente por renderizar um template. Vale lembrar que o ela está substituindo a generic view direct_to_template que esta deprecated.

Como utilizar uma TemplateView:

#urls.py
from django.conf import settings
from django.conf.urls.defaults import patterns, include, url
from django.views.generic import TemplateView

urlpatterns = patterns('',
    url(r"^success/$", TemplateView.as_view(template_name = "success.html")),
)

Com esta implementação ao acessarmos a url "/success" o template "success.html"  será renderizado.

Django 1.4 Favicon and ignorable 404

Como colocar um favicon em um website que utiliza Django?

O que imediatamente vem a mente de qualquer desenvolvedor é  que basta adicionarmos uma configuração no arquivo urls.py e tudo estará certo. E é realmente isso que alguns blogs recomendam ser feito.
Teríamos um fonte parecido com este:

#urls.py
import os
from django.conf import settings
from django.conf.urls.defaults import patterns, include, url
from django.views.generic.base import RedirectView

urlpatterns = patterns('',
    url("^favicon\.ico", RedirectView.as_view(
                            url = os.path.join(settings.STATIC_ROOT,
                                "images/favicon.ico"))),
)

Bom, após alguns testes percebi que, mesmo utilizado servidor de desenvolvimento do Django, descobri que isto não funciona. Pois, este servidor ao receber uma requisição na url "^favicon\.ico", ele
automaticamente redireciona a requisição para: "^images/favicon\.ico".

Pensando um pouco melhor:

Será que o Django, sendo um framework para desenvolvimento web, é responsável por atuar como servidor de arquivos? Acredito que não, porque esta é a responsabilidade do WebServer.
Então, após ler mais um pouco da documentação da release 1.4, encontrei um tópico bastante interessante que descreve padrões de URLS que o Django não reportará erros ao encontrar um 404.

Com isso podemos concluir que este tipo de arquivo não será gerenciado pelo Django e sim pelo WebServer, neste caso para concluir a configuração deverá ser realiza WebServer.

Konira - an rspec like test suite for Python

Boa Noite Senhores!

Para quem já me conhece sabe que sou obcecado por perfeição e qualidade. Para conseguir garantir estas manias tive que recorrer ao TDD, estou programando há alguns anos e ainda não encontrei um caminho melhor  do que escrever testes para o que será desenvolvido visando garantir a qualidade.

Escrever TestCases conforme o padrão jUnit é massante e cansativo (para não dizer um porre). Pois, além do trabalho gasto com os métodos de testes seguindo o padrão: def test_store_data_on_file() é muito fácil perder a linha do que e de como deve-se testar uma funcionalidade.

Mas então, uma solução muito interessante e agradável de escrever os testes para um app é seguindo uma outra corrente, neste caso a denominada: Behavior Driven Development. Para mais referências dê uma olhada no RSpec um framework de testes para Ruby.

Bom, a ideia deste post não é apresentar um framework para Ruby e sim mostrar aos Pythonianos que em um breve futuro poderemos trabalhar com BDD em Python. Trata-se de um projeto novo chamado Konira. Neste projeto está sendo desenvolvida uma DSL que provê suporte à escrita de testes de modo análogo à testes utilizando o RSpec só que em Python e para Python.

Tive a oportunidade de realizar alguns testes com o Konira e creio que em breve tenhamos uma opção estável e acredito mais pythoniana de escrever testes em Python.

Att!

(para instalar o Konira basta: "pip install konira")

Django 1.4 and Pydev

Neste sábado o Django foi atualizado para a versão 1.4 e na mesma hora decidi atualizar os projetos que atualmente desenvolvo devido às boas novidades da versão. Estas podem ser completamente visualizadas em Release notes.

A atualização da versão recomenda que o script "manage.py" seja atualizado, conforme esta  recomendação. Após alterar o script o Pydev, infelizmente, deixa de funcionar pois,
o Pydev sobrescreve a variável DJANGO_SETTINGS_MODULE de acordo com o diretório do script manage.py. Mesmo alterando as configurações do projeto o problema não é resolvido então
 para resolver este problema proponho a utilização deste script no lugar do manage.py padrão.

#!/usr/bin/env python
import os
import sys


if __name__ == "__main__":

    settings_module = "{{ project_name }}.settings"
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", settings_module)
    # Principal Mudanca.
    os.environ["DJANGO_SETTINGS_MODULE"] = settings_module

    from django.core.management import execute_from_command_line
    execute_from_command_line(sys.argv)

Após alterar o script é necessário realizar os seguintes passos para que a depuração funcione corretamente:

Caso queria criar um projeto novo, siga as instruções abaixo:

Para Criar um Projeto Novo

1. Crie um Projeto do tipo Pydev Django Project;
   
   
   
   
   
   
    
   
   
2.  Ao clicar em Finish este erro irá aparecer, clique Ok e siga em frente:
   
   
   
   
   
3. Veja que o projeto foi criado com sucesso, este erro aparece pois o layout padrão do projeto foi modificado, então basta ignorá-lo.
   
   
   
   
   

Pronto, seu projeto está criado.

Configurações de depuração

1. No Eclipse, clique em Debug Configurations, na lista lateral crie uma nova configuração do tipo PyDev Django;
   
   
   
   
   
2. Indique em Projeto indique o projeto MainModule o script manage.py referente ao projeto;
   
   
   
   
   
3. Na Aba Arguments escreva em: Program Arguments: -> runserver --noreload Working Directory -> Selecione Other e escreva ${project_loc:};
   
   
   
   
   
4. Salve a configuração e utilize-a para depuração.
   
   
    
     

Bom só precisa ser feito isso para tudo funcionar, ou voltar a funcionar como antes.

Ao inciar a depuração é comum este erro aparecer Para solucioná-lo basta clicar sobre o nome do projeto que deseja debugar.

Espero ter facilitado a vida de alguém.