Parte 1 - O Projeto

Defini como projeto, algo genrico suficiente para podermos seguir de maneira fcil e possibilitar adpates conforme for o desenrolar do mesmo. Utilizarei no meu exemplo, um sitema para gerenciar cds, dvds e livros de um colecionador. O INCIO Crie uma pasta para armazenar seus projetos, de preferncia um lugar fcil para acessar via prompt (Ex. C:\Projetos). Para criar seu projeto v at sua pasta de projetos e digite o comando: django-admin.py startproject app Neste exemplo, adoto por padro o nome app para meu projeto. Mais a frente entrarei em detalhes sobre isso. Ao executar o comando, na sua pasta de projetos ser criada uma pasta com o nome do projeto escolhido e dentro dela 4 arquivos: __init__.py Este arquivo no ser utilizado por hora, mas ele serve para informar ao django que uma pasta com contedo Python. manage.py Este arquivo ser utilizado mais a frente quando for criar as aplicaes para o projeto settings.py Este arquivo o responsvel por gerenciar todas as configuraes do seu projeto. Entraremos em mais detalhes abaixo. urls.py Este arquivo conter todas as urls de nossas aplicaes mapeadas para suas respectivas views.

O SETTINGS.PY Abra o settings.py da raiz do projeto. Por hora, irei alterar apenas o bsico de forma a colocar o administrativo gerado pelo django com poucas alteraes: coloque o seguinte comando na primeira linha do seu arquivo: from os import path as os_path Nesta linha, estou importando o objeto path do pacote os, e colocando um alias para tal: os_path. Utilzaremos isso logo a seguir para configurar o media.

Os controles de debug servem para o django gerar uma tela erro ao desenvolvedor informando o motivo do erro. Mais a frente tratarei dos erros mais comuns de cometer durente o desenvolvimento. Por hora, deixe as duas linhas como esto:

DEBUG = True TEMPLATE_DEBUG = DEBUG

Vamos criar duas setting neste ponto para definir o caminho e a url do projeto. Coloque os comandos a seguir abaixo dos controles do DEBUG. PROJECT_PATH = os_path.abspath(os_path.split(__file__)[0]) SITE_URL = 'http://localhost:8000/'

Certifique-se que a setting SITE_URL tenha uma barra no final conforme o cdigo acima. Logo em seguida est uma tupla com os administradores do seu projeto. Coloque seu nome e seu email. nos respectivos lugares e descomente a linha. Isso ser util mais a frente quando for colocar para enviar os logs de erros para o email. Deixe seu cdigo assim: ADMINS = ( ('Seu nome aqui', 'seuemail@provedor.com.br'), ) VALE LEMBRAR: A indentao para indicar que os elementos hierarquicamente dispostos tm o mesmo avano relativamente posio (x,0). Na maioria das linguagens a indentao tem um papel meramente esttico, tornando a leitura do cdigo fonte muito mais fcil (read-friendly), porm obrigatria em outras. Python, por exemplo, utiliza esse recurso tornando desnecessrio o uso de certos identificadores de blocos ("begin" e/ou "end"). Para este tutorial utilizarei UM TAB, para cada nvel de indentao

O Banco de Dados Crie uma database no seu banco de dados e configure cada varivel com seu respectivo valor conforme o exemplo abaixo:

DATABASE_ENGINE = 'mysql' DATABASE_NAME = 'app' DATABASE_USER = 'usuario' DATABASE_PASSWORD = 'senha' DATABASE_HOST = '' # deixe vazio para localhost DATABASE_PORT = '' #deixe vazio para porta padrao do banco escolhido. Neste caso 3306.

O usurio informado acima deve ter privilgios para criao/alterao de tabelas, indices etc., na database informada. Acerte tambm o fuso horrio que deseja utilizar: TIME_ZONE = 'America/Sao_Paulo'

Outro recurso muito interessante a internacionalizao. O Django j prov uma serie de facilidades para deixar seu projeto multi-lingua. Mais a frente , mostro como funciona a traduio automtica. Coloque o idioma padro aqui: LANGUAGE_CODE = 'pt-Br' O prximo setting o ID do site que est trabalhando. Com o django possvel utilizar a mesma administrao pra projetos semelhantes porm independentes, gerenciando atravs desta setting. Deixe ela sem nenhuma alterao como descrito abaixo: SITE_ID = 1 A prxima setting referente a internacionalizao. Deixe ela como True que iremos utiliz-la mais a frente. USE_I18N = True

O MEDIA O media onde ficaro todos os arquivos referentes a contedo, como por exemplo pginas de estilos (css) javascripts todos os arquivos vindos de upload pela administrao, tais como fotos, videos, pdfs, etc. A correta configurao do media se faz necessria para acessar os contedos descritos acima. Para definir um padro de configurao, vamos utilizar a setting PROJECT_PATH, defina anteriormente. Deixe a configurao do media da seguinte forma: MEDIA_ROOT = os_path.join(PROJECT_PATH, 'media') MEDIA_URL = '%smedia/' % SITE_URL # trailing slash ADMIN_MEDIA_PREFIX = '%smedia/' % SITE_URL # trailing slash.

No item 1, usaremos o mtodo join do objeto os_path previamente importado para concatenar o caminho do projeto com a string media. J no item 2, ser definido a url do media. O conteudo de %s ser substituido pela setting SITE_URL (outra forma de concatenao de strings), tambm previamente definida. E por fim, no item 3, o caminho do media para o administrativo, igualmente definido no item 2. Para o administrativo do django, no necessrio ter uma pasta media dentro do seu projeto. Farei isso mais a frente quando criar uma aplicao que precisar disso. A setting SECRET_KEY, faz parte do algoritmo de criptografia que o django utiliza para gerar senhas por exemplo. Deixe esta setting sem nenhuma alterao.

A tupla MIDDLEWARE_CLASSES define quais middlewares sero utilizados pelo projeto, por default 3 deles j vem adicionados a lista e por hora so apenas os necessrios. Deixe esta settings tambm sem nenhuma alterao.

ROOT_URLCONF define qual ser o arquivo de urls utilizado pelo projeto. No caso usaremos o criado na raiz do projeto. Por default, essa setting j vem com esse valor, apenas confira para checar: ROOT_URLCONF = 'app.urls'

A tupla TEMPLATE_DIRS a responsvel por mapear os possveis caminhos para seus templates que sero utilizados nas views de suas aplicaes e/ou alguma view personalizada no admin. Este tpico ser discutido mais a frente. Deixe a tupla da seguinte forma: TEMPLATE_DIRS = ( os_path.join(PROJECT_PATH, 'templates') )

E por fim, a setting INSTALLED_APPS a tupla que contm todas as aplicaes instaladas do seu projeto. Vale destacar que se desenvolvido corretamente uma aplicao, possivel torn-la plugvel e utiliz-la em outros projetos de forma fcil e rpida. Por hora apenas adicione a aplicao dos usuarios do admin: INSTALLED_APPS = (

'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.admin', #linha que adiciona o admin

Com o settings.py configurado, v ao promtp, navegue at a pasta do seu projeto (C:\Projetos\app) e execute o seguinte comando para a criao do banco: python manage.py syncdb Isto ir criar todas as tabelas das aplicaes instaladas, com relacionamentos, indices e de uma maneira otimizada. Aps a criao das tabelas, digite yes quando for questionado se deseja criar um super-usurio. Prencha os dados conforme forem solicitados. Este usurio o primeiro usurio com acesso ao administrativo. Trataremos da administrao de usurios na Parte 2.

Para definirmos a url da administrao, abra o urls.py e descomente as seguintes linhas linhas: from django.contrib import admin admin.autodiscover()

e dentro de urlpatterns, descomente a url do admin: (r'^admin/(.*)', admin.site.root), No servidor de teste local do Django, necessrio informar que os conteudos da pasta media so conteudos estticos. No urls.py deixe o incio do arquivo da seguinte forma: from django.conf.urls.defaults import * from django.conf import settings from os import path as os_path

Ainda no urls.py coloque o seguinte cdigo no final do arquivo: if settings.DEBUG:

urlpatterns += patterns('', (r'^media/(.*)$', 'django.views.static.serve', {'document_root': os_path.join(settings.PROJECT_PATH, 'media')}),)

Mais uma vez tome cuidado com a indentao. Feito isso, v at a pasta onde fez o checkout do Django (C:\Django\), e copie as seguintes pastas: C:\Django\django\contrib\admin\media C:\Django\django\contrib\admin\templates Agora v at a raiz do seu projeto e cole-as.

Volte ao prompt e digite o seguinte comando para iniciar o servidor inbutido no django para testes: python manage.py runserver Com tudo corretamente configurado, voc dever receber uma mensagem semelhante : Django version 1.1 pre-alpha, using settings 'app.settings' Development server is running at http://127.0.0.1:8000/

Quit the server with CTRL-BREAK.

Pronto! J temos o servidor do django rodando local para testes. V ao navegador e digite o seguinte endereo: http://localhost:8000/admin/ Com tudo rodando perfeitamente, voc ver uma tela conforme a apresentada na Figura 1:

Figura 1. Interface de login da administrao do Django

Caso queira ver tudo o que foi feito neste passo, acesse a administrao com o super-usurio criado.

Parte 2 - Breve tour pelo admin do Django

Continuando de onde parei no ltimo post, uma funcionalidade muito til que o Django j trouxe pronto: A administrao de usurios. Como bem auto explicativo, apenas vou apresentar brevemente como ficou o admin criado. Depois de logar, ver a home da administrao. nela que estaro todas suas aplicaes instaladas. Como acabamos de criar o admin, este contm apenas o mdulo padro Site, que j vem configurado no settings.py na setting INSTALLED_APPS, conforme vimos na parte 1. O mdulo Auth o mdulo que adiconamos INSTALLED_APPS quando configuramos o settings.py do projeto. ele o responsvel por gerenciar todos os logins e permisses de usurios e grupos, o que se integrado com o usurio do front-end, facilita muito o desenvolvimento. Veremos como integrar o usurio do Django com um usurio do projeto mais a frente.

Tambm na home, apresentado um box a direita que mantm o historrico das modificaes realizadas recentemente na administrao.

Home da administrao

Pr-cadastro dos usurios

Para utilizar a administrao o usurio orbigatoriamente precisa ser um Membro da equipe. Automticamente quando cria-se um usurio este vem com a opo ativo pr-selecionada. Este recurso bastate util caso no queira perder as informaes do usurio em seu projeto, como por exemplo um E-Commerce que existam vrios pedidos associados a este usurio, caso precise "remov-lo", pense na simples opo de desativ-lo, porque SIM, com o Django nada fica rfo no banco.

Permisses Outra facilidade que o Django prov a customizao das permisses por usurios e grupos. Sobre as permisses existem trs opes: ou cria-se um usurio com privilgio de superusurio (o que poupa o trabalho de setar todas as permisses individualmente), ou caso precise de apenas algumas pode set-las com base na lista de permisses. Esta lista tambm vai apresentar todas as aplicaes que voc instalar no seu projeto, ou ainda criar um grupo e setar apenas as permisses do grupo. Os usurios que forem associados ao grupo em questo herdaro as permisses do mesmo.

Edio de permisses

Precisa de um grupo e agora j digitou todas as informaes do seu usurio? Sem problemas. possivel utilizar o smbolo de "+" ao lado da lista de grupos, sem a necessidade de voltar home para criar o grupo pelo mdulo de grupos. Ao criar um grupo por aqui, alm de ele j ser adicionado ao banco, ao clicar em salvar, o Django automaticamente o seleciona para a concluir a crio do usurio. Veremos como fazer isso quando criarmos a primeira aplicao.

Adicionando grupos pela administrao de usurios

Atalhos, buscas e filtros com uma linha de cdigo.

Listagem dos usurios com alguns recursos interessantes

Insira um usurio, edite as permisses, logue com ele para ver as diferenas para sentir uma das vrias facilidades que teremos para os projetos.

Parte 3 - Criao da primeira APP

Dentro da pasta do projeto iremos criar a primeira aplicao deste projeto. Comearei por CD. Navegue at a pasta do projetop via prompt e execute o comando: python manage.py startapp cd Este comando ir criar uma pasta com 3 arquivos: __init__.py models.py Neste arquivo ser colocado todos os modelos da aplica views.py Aqui ficam as views que utilizaremos no front. Voltaremos a falar delas mais a frente.

Por hora abra o models.py. Acima da importao do pacote models, coloque a codificao a ser utilizada: # -*- coding: utf-8 -*from django.db import models

Deixando tudo em UTF-8, problemas de acentuao tanto no banco quanto nos templates sero evitados. Mantenha essa string sempre na primeira linha de todos os models.py e views.py.

CRIANDO O PRIMEIRO MODELO

Nesta aplicao, defini que os cds sero divididos por categoria, intrprete e contero algumas informaes espefficas do album tais como: foto, ano e faixas. Vamos ao cdigo:

A classe categoria: class Categoria(models.Model):

nome = models.CharField(max_length=100) slug = models.SlugField(max_length=100) class Meta: ordering = ['nome']

def __unicode__(self): return self.nome

A classe categoria herda as propriedades da classe Model, por isso o import nas primeiras linhas. Os atributos: nome = models.CharField(max_length=100) slug = models.SlugField(max_length=100)

Ambos sero renderizados como um INPUT TEXT no admin, porm o campo slug gera uma melhor indexao no banco, alm de ser o grande responsvel pelas urls elegantes que criaremos para as views. Em ambos os casos o parmetro max_length obrigatrio. O campo slug ser utlizado de forma a identificar um registro nos banco de forma nica no banco, e ser preenchido de uma forma interessante quando chegarmos na administrao desse modelo. A classe Meta, que est definida dentro de da classe recm criada possui muitos recursos interessantes. Para categoria, estou utilizando apenas a ordenao padro quando os objetos da mesma forem listados: ordering = ['nome'] Com o ordering posso colocar a ordenao por quaisquer atributos pertencentes a minha classe, e utilizar o sinal "-" (menos) para ordenao decrescente, como por exemplo:

ordering = ['-id']

O mtodo __unicode__ o responsvel por retornar uma string contendo o conteudo de qualquer campo da instncia do objeto em questo. Caso ele no esteja defindo, ocorre a seguinte diferena para um objeto c pertencente a esta classe: c - retornaria: OBJECT c.nome - retornaria o valor do atributo nome J com o __unicode__, ambos os casos retornariam diretamente o valor, o que poupa trabalho.

A classe Interprete: class Interprete(models.Model):

nome = models.CharField(max_length=100) slug = models.SlugField(max_length=100) def __unicode__(self): return self.nome

class Meta:

ordering = ['-id'] verbose_name = u'Intrprete' verbose_name_plural = u'Intrpretes'

Aqui temos dois novos recursos da classe meta. possivel setar qual ser o nome no singular e no plural atravs do verbose_name, de forma a deixar correto (com acento) no admin.

A classe Album:

class Album(models.Model):

categoria = models.ForeignKey(Categoria) interprete = models.ForeignKey(Interprete) titulo = models.CharField(max_length=255,verbose_name=u'Ttulo') cover = models.ImageField(upload_to='albuns/%Y/', null=True, blank=True) ano = models.IntegerField() slug = models.SlugField(max_length=255) def __unicode__(self): return self.titulo

class Meta:

ordering = ['-id'] verbose_name = u'Album' verbose_name_plural = u'Albuns'

Aqui temos algumas novidades em relao as anteriores: - possivel utilizar o verbose_name para atributos de forma a corrigir o nome mostrado no admin, conforme visto no ttulo; - Para nomes com acentos, se faz necessrio colocar a letra "u" antes da string com o mesmo, para ficar correto com a codificao; - um campo do tipo Imagem para fazer o upload da capa do lbum. O parmetro upload_to obrigatrio e deve ser a string do caminho onde ficaro as imagens. Tambm possivel organizar os uploads por datas. Neste exemplo, ser gerada a pasta albuns dentro do media, e dentro dela, uma pasta com o ano que fez o upload defindo pelo caracter "%Y". Observao: o ano do lbum no est relacionado com o caminho do upload; - Para o campo cover, temos dois parmetros opcionais que permitem ao usurio criar um lbum sem a necessidade de preencher este campo. Colocando ambos campos em um atributo, o django exclui o mesmo da validao automtica. - Temos duas chaves estrangeiras para a classe album: categoria e interprete. Previmente definidos;

- E por fim, o campo do tipo inteiro ano, que tambm ser renderizado como um INPUT TEXT no admin.

A classe Faixa: class Faixa(models.Model):

album = models.ForeignKey(Album) nro = models.IntegerField(verbose_name = u'Nmero') nome = models.CharField(max_length=200) tempo = models.CharField(max_length=10, help_text='Formato MM:SS',blank=True,null=True) def __unicode__(self): return self.nome

A novidade na classe faixa uma dica dada ao usurio sobre o correto preenchimento para um campo na administrao. Utilizando o atributo opcional help_text, a mensagem desejada aparece ao lado do campo escolhido.

CRIANDO O ADMIN PARA O MODELO Crie dentro da pasta da sua aplicao um arquivo com o nome de admin.py. Dentro dele precisaremos de dois imports: from django.contrib import admin from app.cd.models import * O primeiro para as funcionalidades do admin em si, e o segundo para as informaes do modelo criado. Logo abaixo, ser criado as classes do administrativo:

O admin de Categoria: class CategoriaAdmin(admin.ModelAdmin):

search_fields = ('nome',) list_display = ('nome',)

prepopulated_fields = {'slug': ('nome',)} save_on_top = True

search_fields - recebe uma tupla com os campos em que ser realizada uma busca por quaisquer ocorrncias do que for digitado. list_display - recebe uma tupla com os campos que aparecero na listagem prepopulated_fields - aqui um recurso interssante do django para o campo slug. O preenchimento automtico do campo slug com o texto do quer for inserido no campo nome, com excesso de algumas palavras reservadas, espaos e acentuao. save_on_top - til para formulrios grandes. Esta opo replica a barra de controle para salvar/apagar registros acima do form.

O admin de Interprete:

class InterpreteAdmin(admin.ModelAdmin):

search_fields = ('nome',) list_display = ('nome',) prepopulated_fields = {'slug': ('nome',)} save_on_top = True

Vamos utilizar um recurso muito interessante para as duas classes que faltam. Imagine se tivesse que inserir primeiro lbum com todas as informaes, depois ir at o administrativo de faixas para inserir uma a uma tendo que escolher o lbum. Trabalhoso demais. O Django possui uma soluo para isso. possvel utilizar um recurso chamado INLINE, para adicionar uma ou vrias faixas durante a insero do lbum. Vejamos como:

O admin inline de Faixa: class FaixasInline(admin.TabularInline):

model = Faixa extra = 15

Esta classe herda de uma classe diferente das outras extamente por possuir esse recurso. Apenas precisamos definir a qual modelo ela se refere: model = Faixa

E a quantidade de itens que sero exibidas alm dos preenchidos: extra = 15

O admin de Album:

class AlbumAdmin(admin.ModelAdmin): inlines = [ FaixasInline,

] raw_id_fields = ('categoria','interprete',) search_fields = ('titulo',) list_display = ('titulo','interprete','categoria','ano') list_filter = ['categoria'] prepopulated_fields = {'slug': ('titulo',)} save_on_top = True

Novidades desta classe: - Nesta classe, definido que ser utilizado a classe FaixasInline criada anteriormente - Como provavelmente teremos muitos artistas e categorias, procur-los em um campo do tipo SELECT (tipo renderizado pelos campos ForeignKey) seria um tanto trabalhoso. Com a opo raw_id_fields, aberto uma nova janela com a listagem definida pela referncia a chave estrangeira, de forma a utilizar todas as buscas, filtros e ordenao providas pelo admin da mesma. - list_filter - gera um filtro para facilitar a busca de um registro. O filtro s exibido quando esta classe possuir registros pertencentes a mais de uma classe do filtro.

O admin de Faixa: class FaixaAdmin(admin.ModelAdmin):

search_fields = ('nome',) list_display = ('nome','album','nro','tempo') save_on_top = True

Para concluir o admin.py, registre os admins criados ao final do arquivo:

admin.site.register(Categoria, CategoriaAdmin) admin.site.register(Interprete, InterpreteAdmin) admin.site.register(Album, AlbumAdmin) admin.site.register(Faixa, FaixaAdmin)

TESTES

Adicone dentro do INSTALLED_APPS no settings.py a aplicao criada.

INSTALLED_APPS = (

'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.admin', 'app.cd',

Pare o servidor local de testes caso esteja rodando e execute um syncdb para gerar as tabelas. Inicie novamente o servidor de testes com o runserver e abra o admin do seu projeto no link:

http://localhost:8000/admin/

Parte 4 - Criando views

Para concluir essa primeira fase do tutorial, faremos agora exemplo com duas views para a aplicao CD. Abra o arquivo views.py e o deixe da seguinte forma: # -*- coding: utf-8 -*# Create your views here. from django.shortcuts import render_to_response from app.cd.models import Interprete, Album def listaInterpretes(request):

interpretes = Interprete.objects.order_by('nome') return render_to_response('cds/interpretes.html', {'interpretes':interpretes,})

def listaCds(request,slug=None):

cds = Album.objects.filter(interprete__slug = slug) return render_to_response('cds/cds.html', {'cds':cds,})

A funo render_to_response a responsvel de passar todos os objetos para o template especificado. Para listar os intrpretes, utilizaremos def listaInterpretes. Todas as defs criadas no views.py para utilizao no front precisam do parmetro obrigtorio resquest. Atravs dele, ser possvel pegar contedos dos POSTs, GETs e SESSIONs. A primeira linha da def listaInterpretes, a responsavl por pegar todos os registros contidos no banco para esta classe e atravs do mtodo order_by, os registros j viro ordenados pelo campo solicitado, neste caso, o nome. Ao clicar no nome do intrprete, queremos mostrar quais cds esto relacionados a ele. Faremos isso utilizando alistaCds. Da mesma forma que fizemos com a primeira def, ser necessrio pegar todos os cds, porm agora temos uma restrio: mostraremos apenas os cds vinculados ao intrprete escolhido. Vamos enteder como isso ser feito: cds = Album.objects Neste ponto, temos todos os cds contidos no banco de dados. Para filtrar apenas os relacionados ao intrprete escolhido utilizaremos o mtodo filter.

Nossa chave estrangeira interprete da classe Album uma conexo direta aos objetos da classe Interprete, sendo possivel desta forma acessar quaisquer conteudos l contidos. Lembra do campo slug do model? Aqui ele ser utilzado. Cada intrprete possui um slug, e como ele estar contido na url, por que no utiliz-lo para o filtro? extamente isso que iremos fazer. No comando filter, vamos filtrar pelo campo slug da classe Interprete da seguinte forma: filter(interprete__slug = slug) O parmetro slug desta def ser passado pela url. Com as defs prontas veremos agora como criar tais urls para deix-las elegantes e funcionais. O URLS.PY Adicone ao urls.py da raiz do seu projeto a seguinte linha abaixo da url do admin: (r'^cds/', include('app.cd.urls')), Esta linha importar todas as urls contidas no urls.py da sua aplicao cd. possivel coloc-las no arquivo urls.py da raiz, mas por questo de organizao, criaremos um outro urls.py dentro da aplicao, referenciando as mesmas travs do include acima, mapeadas pela url: /cds/. Agora crie dentro da pasta cd, um arquivo chamado urls.py e deixe-o da seguinte forma:

from django.conf.urls.defaults import * urlpatterns = patterns('app.cd.views',

(r'^$', 'listaInterpretes'), (r'^interpretes/$', 'listaInterpretes'), (r'^(?P<slug>[-\w]+)/$', listaCds),

Com as importaes necessrias, definiremos os padres de urls desta aplicao. Neste exemplo esto sendo criadas trs urls: /cds/ Ir funcionar de maneira similar ao index.html em uma pasta qualquer. Essa urls chamar a def listaInterpretes contidas no views.py da aplicao cd. /cds/interpretes/ Esta url ter a mesma funcionalidade da anterior.

/cds/ Aqui, o slug do intrprete ser passado atravs da expresso regular para texto : [-\w]+ , que chamar a def listaCds, passando o segundo parmetro necessria para a listagem de cds: o slug do intrprete.

OS TEMPLATES Criarei os dois templates dos exemplos acima de forma bem simples, apenas para servir de exemplo. Dentro da pasta templates na raiz do projeto crie a pasta cds. Dentro dela crie os dois arquivos abaixo: interpretes.html

Na linha 14 da imagem a acima, temos um for que ir passar por todos os registros vindos o objeto interepretesque foi passado na view. Para cada registro, ser criado um link para redirecionar at SLUG/, onde o mesmo ser o valor contido no atributo slug do objeto i corrente. Conforme vimos anteriormente, o parmetro slug, ser passado atravs da expresso regular contida no urls.py que foi criado na aplicao. Vejamos o outro template a ser criado:

cds.html

Neste template, apenas temos um for, que ir correr todos os registros do objeto cds filtrados pelo slug do intrprete, conforme vimos na view.

OBSERVAES: Note que as variveis apenas so ACESSADAS no template, no possivel defin-las no mesmo. Para os comandos, deve-se utilizar o bloco: {% comando %} com seu respectivo bloco de fechamento {% endcomando %}. Para acessar o contedo dos objetos deve-se utilizar: {{ obj.atritbuto }}, conforme nos exemplos acima.

Agora basta iniciar o servidor e acessar http://localhost:8000/cds/, se estiver rodando local. Repositrio atulizado at este post: Revisao 7.

Parte 5 - Integrando o cadastro aos usurios do Django

Neste tpico, mostrarei um dos muitos recursos do Django em detalhes: a Integrao do cadastro do projeto ao usurios Django. Vamos primeiro entender do que se trata. Cadastro uma das muitas aplicaes que geralmente temos em todos os projetos, e muita das vezes, os usurios que se cadastrarem tem acesso privilegiado algumas sees. Para restringir o acesso no autorizado ao contedo controlado, era necessrio controlar em todas as

pginas se o usurio estava logado, se tinha permisso de fazer quela requisio, etc. No Django h uma forma fcil de fazer isso. Vamos ao cdigo. Crie sua aplicao cadastro: python manage.py startapp cadastro

E deixe o model da seguinte forma:

O relacionamento da classe cadastro recm criada e a de usurios do Django ocorre na linha 11, onde temos uma FK para a classe User, importada na linha 2. Outra coisa interessante, a linha 3, onde importamos a lista de estados brasileiros provida pelo prprio Django. Utilizo esta lista na linha 25 para prover uma escolha no campo estado da classe cadastro. Abaixo da classe meta que vimos nos posts anteriores, temos um mtodo muito importante. A def save a responsvel por fazer a persistencia dos dados no banco. O que estou fazendo nesta classe simplemente sobrescrevendo ela, de forma a funcionar como preciso. Quando um objeto adicionado ao banco, o mtodo save chamado e instancia um objeto de uma classe, setando os valores passados para cada respectivo atributo. Caso for sobrescrever a def save, necessrio prever as duas situaes: quando um objeto for inserido ou quando for alterado. Em ambos os casos, o o save chamado. Para testar qual caso estaremos lidando basta fazer o teste da linha 36: if not self.id: Se no existir conteudo dendo do atributo id do objeto atual, o mesmo estar sendo inserido ao banco de dados, caso contrrio, alterado.

Neste exemplo utilizaremos o email como usurio. Como o usurio do Django tem que ser nico, farei alguns tratar isso. Na linha 37, feito uma busca no banco de cadastro para verificar se o email j existe no sistema. c = Cadastro.objects.filter(email=self.email).count() Caso o email existir (linha 38), levantaremos uma exceo EmailExistente impedir o cadastro. Veremos como utilizar as excesses mais a frente. Nas linhas 41 47, feito uma verificao para saber se o usurio j existe. Caso existir, o mesmo atribudo ao objeto u, caso contrrio, criado um novo usurio com base no email e senha fornecidos e atribuido ao objeto u. Em ambos os casos, o objeto u salvo e a FK para a classe User setada com o mesmo.

Para alterao (linhas 48 52), basta setar os atributos da classe user com os novos dados forncecidos.

Aps este tratamento, ser chamado o mtodo save original para fazer a persistncia, passando os seguintes parmetros: a classe Cadastro e nosso objeto em questo (self), da seguinte forma: super(Cadastro, self).save()

As classes CadastroPF e CadastroPJ, so classes normais iguais as que j foram feitas, com apenas uma diferena: no herdam da models.Model, mas sim da classe Cadastro, onde temos os atributos comuns s duas. Crie o restante das classes conforme a figura abaixo:

Crie um admin.py da seguinte forma:

Note que apesar de criar uma administrao pra classe Cadastro, esta no est registrada na administrao. Desta forma, apenas ser inserido um cadastro de pessoa fsica ou jurdica, e veremos a herana funcionado.

Instale sua aplicao no settings, sincronize o banco, inicie o servidor e faa os testes necessrios.

Parte 6 - Login com autenticao pelo sistema do Django

Neste post veremos como fazer a autenticao com o login do django criado na parte 5. Primeiro, abra o settings.py do seu projeto e adicione as seguintes linhas abaixo da setting ROOT_URL:

Essa tupla ir passar diretamente para o template os modulos de request, autenticao, debug e internacionalizao. No caso do request, isso poupar muito trabalho nos templates, pois desta forma acessaremos POST, GET e SESSION de forma direta.

Coloque tambm no settings.py, abaixo das configuraes do banco de dados as seguintes settings: # ESQUEMA DE LOGIN AUTH_PROFILE_MODULE = 'cadastro.cadastro' LOGIN_URL = '/cadastro/login/'

Estas settings definem que o mdulo de autenticao ser o modulo de cadastro e qual a url para efetuar o login. Esta url ser utilizada mais a frente.

Com o settings.py alterado, deixe o views.py do mdulo de cadastro da seguinte forma:

Ver imagem completa

Na linha 3 temos a importao dos metodos de autenticao que utilizaremos. Para acessar o request de forma direta no template (sem a necessidade de pass-lo em todos os render_to_response) se faz necessrio a importao da linha 5 e o parmetro opcional abaixo para o template em questo: context_instance=RequestContext(request, {})

Neste exemplo, utilizarei a mesma def para exibir o formulrio e para efutar o login. Na linha 10, caso j exista o id do usurio vindo pelo request, significa que o usurio j est logado no sistema, caso contrrio ir para o teste seguinte na linha 14. O metodo authenticate utilizado na linha 17 o responsvel por tentar recuperar o usurio que contenha nos atributos username e password os valores postados pelo formulrio. Se o objeto u receber um valor vlido para usurio (linha 18) e se o atributo is_active (usurio ativo, linha 19) for True, o mtodo authlogin far a autenticao para o usurio em questo. Na linha 22 temos um recurso interessante do Django. Caso seja solicitada uma view que requer login, automaticamente isto ser tratado e usurio ser redirecionado para o formulrio de login (definido na settingLOGIN_URL previamente descrita). Quando o mesmo entrar com usurio e senha, o usurio ser redirecionado para o link previamente solicitado que passado por GET para a varivel next. Veremos abaixo como definir que uma view precisar de login. O Django tambm j possui implementado o mtodo de logout (linha 30) que tira o usurio logado de todos os atributos da SESSION. Vamos ver como obrigar o usurio logar para ver um determinado contedo. Abra o arquivo cd/views.py e

deixe-o da seguinte forma:

Aqui a alterao bem simples, apenas precisamos importar o decorator login_required com a linha 6, e utiliz-lo logo antes de cada def que desejarmos, como visto na linha 8. Toda vez que a def escolhida for chamada, ser feito a verificao de login para a exibio da mesma.

Agora apenas falta criar os htmls e as urls para login. Crie 2 htmls conforme as imagens abaixo: login.html

logado.html

Crie um arquivo com nome de urls.py dentro da app cadastro da seguinte forma:

Agora basta dar o include das urls de cadastro no urls.py da raiz do projeto: (r'^cadastro/', include('app.cadastro.urls')),

Rode o projeto com o comando runserver e faa os testes necessrios.