O Django, como sabemos, é um framework desenvolvido em Python. A grande função de um framework é automatizar determinadas tarefas no desenvolvimento de sistemas/site, como também facilitar tal desenvolvimento, evitando que o desenvolvedor tenha que ficar repetindo várias vezes a mesma tarefa – por isso temos no Django o conceito de DRY (Don’t Repeat Yourself) ou “não se repita”.

Um bom exemplo do conceito do DRY são os comando de banco de dados também conhecido como CRUD (Create, Read, Update, Delete). O Django traz nativamente o ORM para os banco de dados MySQL, PostgreSQL, Oracle, SqlLite, tendo também inúmeras bibliotecas para outros bancos, como por exemplo MongoDB.

O Django segue a orientação à objeto, possuindo características como classes, atributos, métodos, herança, dentre outras. Quando falamos de classes, temos inúmeras, como Model, Form e Admin. Essas classes herdam de objetos como o models.Model, forms.Form, admin.ModelAdmin respectivamente, não sendo essas as únicas classes que tais elementos podem herdar – já identificamos aqui outra característica da orientação a objetos.

O Model

Esse objeto/arquivo é onde o desenvolvedor cria toda a estrutura do sistema, podendo ser considerado o principal objeto dentro de uma aplicação e possui uma estrutura bem básica, sem muitos mistérios, como tudo no Django.

Como no Django um sistema é composto por várias app’s, cada uma sendo responsável por gerenciar determinada informação, em cada app teremos, na maioria dos casos, uma estrutura de arquivos .py.

Como estamos tratando da classe Model, iremos encontrá-la no arquivo models.py e veremos uma estrutura básica conforme abaixo.

Na linha 236 temos a declaração da classe, onde temos o nome da classe (que nesse caso é Foto), e entre parênteses o models.Model, que será o objeto do qual a classe Foto herdará as características, atributos, método e funções. Na linha 237, temos o o docstring, que segundo a PEP, deve ser utilizado para documentar a minha classe – nesse caso reduzi a documentação por economia de espaço. Nas linhas 238 e 239 temos a declaração dos atributos da classe, que serão “traduzidos” pelo Django para tipos de dados do SGBD que escolhermos, tendo nesse caso dois tipos de dados: um ForeignKey e outro ImageField. Na linha 241 temos a declaração de um método da classe e entre parênteses os atributos desse método.

O Admin

Uma das grandes facilidades que o Django traz para os desenvolvedores é a geração de forma “automática” das interfaces de gerenciamento dos dados, não podendo confundir com os templates do site ou sistema. Quando desenvolvemos um site/sistema, precisamos de uma interface para possibilitar ao(s) administrador(es) do sistema gerenciarem as informações, realizando inserts, updates e deletes, e no Django o objeto responsável por essas tarefas é o admin.py. O admin herda diretamente do admin.ModelAdmin e nele podemos configurar como os dados serão “listados” para o usuário, podemos conformar a disposição dos campos na tela, podemos também ocultar determinados campos e ainda torná-los campos apenas de leitura.

Dentre as inúmeras configurações que podemos fazer, vou destacar aqui as mais utilizadas:

1. search_fields: responsável por determinar quais campos serão utilizados na busca;
2. list_per_page: responsável por controlar a quantidade de itens exibidos na listagem;
3. list_display: tupla com os campos que serão mostrador na tela de listagem(change_list);
4. inlines: tupla onde podemos configurar admin’s de outros models que possuem relacionamento com o admin que estamos configurando, explicarei melhor mais à frente este item;
5. fieldsets: tupla onde configuramos como os campos do nosso admin serão mostrados no formulário de inserção/atualização.

O Form

Mesmo tendo no admin um grande aliado para geração do front-end de gestão dos dados do nosso sistema, teremos ainda duas necessidades, customizar determinados campos e comportamento do form dentro do admin, e também export para fora do admin um front-end para que o visitante do nosso site possa, quando necessário, efetuar o CRUD.

Para ficar mais claro, vamos imaginar que precisamos criar um formulário de contato para um site de um cliente x, onde ele deseja que o formulário tenha os campos: Nome, Email, Telefone, Cidade, Estado, Assunto e Mensagem. A imagem acima mostra exatamente a criação de um formulário de contato, seguindo os padrões de orientação à objeto do Django, perceba que ele herda de forms.Form. Para que possamos criar o formulário HTML originado dessa estrutura, precisaremos da ajuda do objeto views.py que veremos adiante, entretanto como forma de esclarecimento, no nosso template de contato basta fazermos {{ form_contato.as_p }} ou {{ form_contato.as_table }}.

A Views

Podemos tratar a views como o meio de campo entre o usuário/visitante e as operações do Django em si, como a persistência de uma informação no banco de dados, ou o envio de um e-mail por meio de um formulário de contato. Continuando com o exemplo acima de um formulário de contato, quando o usuário preencher os dados e clicar no botão enviar, “alguém” deverá tratar esse comando. E é justamente a views quem faz isso, recebendo as informações preenchidas no formulário, fazendo o tratamento necessário e depois executando a operação desejada – que nesse caso é enviar uma mensagem, acima temos justamente uma views responsável pelo envio de um e-mail com os dados fornecidos pelo visitante.

As urls

Apesar de pequeno, esse objeto é um dos mais importantes no framework (opnião pessoal, pois é ele quem “traduz” a interação do usuário para uma views). Pode parecer confuso, mas podemos criar uma analogia com a brincadeira do telefone sem fio, só que nesse caso a mensagem sempre chega correta, onde a interface do site em HTML recebe alguma interação do usuário, por exemplo o clique do botão de enviar mensagem de um formulário, essa ação é “interpretada” por alguma linha no arquivo urls.py, que a mesma também identifica qual views deve ser acionada para executar a ação que o usuário solicitou.

Não se preocupe, pois esse artigo foi apenas uma passada rápida em cada elemento de uma app no Django. Mais tarde iremos tratar com mais detalhe cada uma delas.

>>> print u’%s’ % (“Abraços”)