Exemplo em Django – parte 2

django-2_abertura

Continuando com o desenvolvimento da “Agenda de Eventos”. Na primeira parte foi criado, através do virtualenv, um ambiente de desenvolvimento e instalado o Django nele. E a partir das ferramentas do framework foi criada a estrutura de um novo projeto (“Agenda”) e nele uma nova aplicação (“events”).

Nesta parte, além de mais um pouco de teoria, a definição do modelo de dados da aplicação (ou apenas modelo) e configuração da interface de administração do Django.

Modelo

No modelo são definidos o comportamento e os campos necessários daquilo que será armazenado (ou persistido) pela aplicação. Cada modelo é definido como uma subclasse de django.db.models.Model e com cada campo correspondendo a um atributo desta.

Cada classe é mapeada como uma tabela no banco de dados.

O que será armazenado?

Por enquanto, a “Agenda de Eventos” armazenará uma relação de eventos e que consiste nas seguintes informações:

  • Dia, mês e ano do evento;
  • Descrição do evento e
  • Prioridade do evento.

Claro que estou assumindo aqui que um evento só ocorrerá durante um dia, que não haverá repetições de eventos e que uma simples descrição é mais que suficiente para identificar um evento dos demais.

Criando um modelo

Dentro do arquivo “./events/models.py” crio uma nova classe, a Event, contendo o atributos relativos à informação que será armazenada.

class Event(models.Model):
    date = models.DateField()
    event = models.CharField(max_length=80)
    priority = models.CharField(max_length=1)

Tanto models.CharField() como models.DateField() são tipos de dados do Django que tem correspondência direta com seus análogos do SQLite para texto e data. O SQLite é usado por padrão mas outros SGBD podem ser utilizados.

Preferi também criar uma lista com descrição das prioridades ao invés de fazê-lo em uma segunda tabela. Daí defino “priorities_list” e a configuro como sendo a lista de opções do atributo “priority”.

class Event(models.Model):
    priorities_list = (
        ('0', 'Sem prioridade'),
        ('1', 'Normal'),
        ('2', 'Urgente'),
        ('3', "Muito Urgente'),
    )
    ...
    priority = models.CharField(max_length=1,choices=priorities_list)

Daí, é definir o método __str__() para produzir uma string “amigável” para o objeto.

class Event(models.Model):
    ...
    priority = ...
    def __str__(self):
        return self.event

Assim, ao se “imprimir” o conteúdo do objeto, o método será chamado e retornará apenas o que foi definido, o nome do evento (depois pode ser melhorado).

Migrando o modelo

Para que o Django consiga acessar corretamente o banco de dados, é necessário criar os arquivos de migração, ou seja, o roteiro com as alterações que se fazem necessárias no banco de dados para refletirem o que foi definido no modelo (sim, sempre que o modelo foi alterado será necessário executar esta operação).

$ ./manage.py makemigrations
Migrations for 'events':
  events/migrations/0001_initial.py
    - Create model Event

Apenas como curiosidade, já que não é um passo obrigatório, é possível verificar o que será executado no banco de dados durante esta fase.

$ ./manage.py sqlmigrate events 0001
BEGIN;
--
-- Create model Event
--
CREATE TABLE "events_event" ("id" integer NOT NULL PRIMARY KEY AUTOIN
CREMENT, "date" date NOT NULL, "event" varchar(80) NOT NULL, "priorit
y" varchar(1) NOT NULL);
COMMIT;

Para aplicar as alterações no banco de dados.

$ ./manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, events, sessions
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying events.0001_initial... OK
  Applying sessions.0001_initial... OK

Além do modelo definido em Event também foram também criados/atualizados outros modelos utilizados dentro da infraestrutura do Django, entre eles o módulo de administração.

Object Relational Model

O Django ORMObject Relational model — age como uma camada que abstrai o método de acesso ao banco de dados e permite que ele seja feito diretamente em Python — tal qual o Active Record faz no Rails.

É possível demonstrar o funcionamento do ORM utilizando o console interativo — shell — do Django.

$ ./manage.py shell
Python 3.6.3 (default, Oct 3 2017, 21:45:48) 
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more
information.
(InteractiveConsole)

Este comando executará o Python em modo interativo e importará automaticamente as bibliotecas do Django configurados dentro do projeto.

Daí é importar a classe Event que está no arquivo “./events/models.py”.

>>> from events.models import Event

E pronto, o modelo estará totalmente acessível a partir do console.

Inserindo registro

Para inserir um novo registro no console interativo você cria uma instância da classe e define os respectivos valores dos atributos.

>>> e = Event() 
>>> e.event = 'Primeiro evento da agenda'
>>> e.date = '2018-04-13'
>>> e.priority = '0'

Depois basta chamar o método save() para que se efetue a inserção do registro.

>>> e.save()

Uma forma mais simples de executar o mesmo procedimento.

>>> e = Event(event = 'Segundo evento da agenda', \
... date = '2018-04-13', \
... priority = '1')
>>> e.save()

Como no exemplo anterior continua sendo necessário chamar o método save().

Consultando registros

Agora que existe alguma coisa no banco de dados é possível consultá-los.

>>> todos = Event.objects.all()
>>> for i in todos:
... print(i)
... 
Primeiro evento da agenda
Segundo evento da agenda

Isto recuperará todos os registros armazenados no modelo (tabela).

Também é possível acrescentar outros métodos para filtrar atributos, alterar a ordem, quantidade etc dos registros mas isto ficará mais para frente.

Alterando os registros

A alteração do valor de todos ou de um campo do registro pré existente é bastante simples.

>>> e = Event.objects.get(id=2)
>>> e.event
'Segundo evento da agenda'
>>> e.event = 'Segundo evento da agenda (editado)'
>>> e.save()
>>> Event.objects.all()
,
Segundo evento da agenda (editado)>]>

O método get() serve para selecionar um registro específico — o de “id” com valor 2, o segundo registro que foi inserido — e então alterar o valor do atributo “event” e depois usar save() para armazenar a alteração na base de dados.


O método para apagar um registro é o remove() mas não quero apagar os eventos da agenda, ao menos não por enquanto… 🙂

Interface de administração do Django

django-2_administração

O Django possui uma interface de administração embutida onde é possível manipular as informações armazenadas pelos modelo. Ela vem habilitada por padrão e para ter acesso a ela é necessário, primeiro, criar criar superusuário (ou administrador).

$ python manage.py createsuperuser
Username (leave blank to use 'giovanni'): giovanni
Email address: ░░░░░░░░░░░░░░░░
Password: ░░░░░░░░░░░░░░░░
Password (again): ░░░░░░░░░░░░░░░░
Superuser created successfully.

Escolha aqui os valores que desejar (apenas se certifique de não esquecer a senha depois).

Também é necessário editar o aquivo “./events/admin.py” para tornar o modelo Event disponível nele.

from django.contrib import admin
from .models import Event

admin.site.register(Event)

E pronto, basta acessá-la em 127.0.0.1:8000/admin e autenticar!

Fim desta parte

Antes de terminar…

$ cd ./events
$ git add admin.py models.py migrations/0001_initial.py
$ git commit -m "inclusão do modelo"

Apenas lembrando que o banco de dados, o arquivo “db.sqlite3”, está fora do repositório do Git e, portanto, não estará sendo versionado e caso ele seja apagado o comando ./manage.py migrate poderá recriá-lo a qualquer momento.

Na próxima parte será a vez de trazer os demais componentes do modelo MTV com a definição de alguns templates (gabaritos), views (visões) e, claro, das urls respectivas.

Até!

Anúncios

3 comentários sobre “Exemplo em Django – parte 2

  1. Reiniciei o processo mas não tive sucesso… o virtualenv não é reconhecido… cheguei a usar um script (setup.sh / VagrantFile) para provisionar uma vm mas tbm não funcionou. Tens paciência pra me sugerir uma saída ? desde apt remove … apt purge … Obrigado

    Curtir

  2. Obrigado pela atenção. Vou fazer nova tentativa e registrar os acontecimentos . Uso ubuntu 17.10. Se recomendas criar uma ubuntu16.4 com vagrant aguardo um sinal… Na falta do sinal instalarei direto no micro/ubuntu.

    Curtir

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

w

Conectando a %s