DEV Community: Renato Lelis

O uso de namespace no Django

Renato Lelis — Thu, 02 Jan 2020 18:43:55 +0000

Segundo o Zen Of Python, namespace são uma ótima ideia e no Django elas estão presentes e eu diria que são essenciais para ter um código fácil de ler e de manter.

No Django, os namespace estão presentes na nomeação das urls (exato, dá para colocar nomes às urls) e na estrutura de pastas dos templates e recursos estáticos.

Nas urls

Nas urls, o uso de namespace aparece em dois momentos. Quando se dar um nome a uma função que está sendo roteada e quando o arquivo de urls pai está direcionando as requisições para um arquivo de urls filho.

Aqui, quando uma requisição for direcionada à rota 'https://<dominio.com>/usuario', as requisições vão ser redirecionadas para as urls do arquivo url.py no modulo usuario. O argumento namespace vai ser o nome do app para qual o as requisições irão ser redirecionadas.

No arquivo de urls filho, deve-se criar uma variável chamada namespace, seu valor sendo o mesmo nome dado no arquivo de urls pai, e o último argumento da função “path” vai ser o nome da função. Internamente, o Django vai concatenar esses dois nomes, ficando “usuario:list”. Isso é útil quando você precisar redirecionar esta url. Em vez de usar “/usuario/usuarios” você usar “reverse(‘usuario:list’)”, mais legível e mais prático.

Dentro das páginas html, as urls também podem ser referenciadas pelo namespace. Usando a tag especial url, você pode converter de namespace para url seguindo o mesmo princípio de legibilidade e praticidade.

Nos templates

Nos templates, os namespaces ajudam a referenciar os arquivos html e os arquivos estáticos dentro de funções e até dentro dos próprios templates.

Ao criar um app no Django que irá conter templates, o indicado é criar uma pasta chamada “templates” e dentro dela criar outra pasta com o mesmo nome no app e aí sim guardar as páginas html dentro desta última pasta.

O mesmo vale para os arquivos estáticos. Se cria uma pasta chamada static, uma com o mesmo nome da app e as pastas dos respectivos tipos de arquivos (css, imagens e javascript).

No código, os templates vão ser referenciados nas views.

Assim como nas urls basta passar o nome do app e, separando por uma barra, o nome do arquivo html.

Os arquivos estáticos vão ser referenciados dentro dos templates.

Os namespace são passados na tag static, passando o caminho relativo, seguindo o exemplo dos templates. Para usar a tag static é preciso carregá-la através da tag load, bem na linha 1.

O próximo programador que irá dar manutenção ao seu código agradece

Vimos nesse artigo o quanto namespaces nos ajudam na leitura do nosso código e facilita a manutenção.

É importante lembrar de escrever código que outros programadores entendem, não só você.

E nisso, o Django ajuda e muito.

Entendendo a arquitetura do Django

Renato Lelis — Thu, 02 Jan 2020 18:28:44 +0000

No início do desenvolvimento de um sistema, é importante que o desenho da arquitetura esteja bem definida e que todos os desenvolvedores sigam ela a risca (bom item para o peer review). No desenho da arquitetura, é levado em consideração performance, escalabilidade e manutenção.

A muitas arquitetura usadas por padrão hoje em dia e alguns frameworks são construídos para seguir elas. No caso do Django o modelo adotado é a arquitetura MTV.

Dividida em três camadas, a arquitetura MTV consiste na camada Model, Template e da camada View.

A camada Model é responsável pela interface com o banco de dados. É onde o Django fornece sua ORM para a modelagem de dados.

Obs: O Django já fornece uma tabela padrão de usuários, o código acima é só um exemplo da ORM.

O Model vai servir como base da aplicação, onde vai ser extraído e persistido informação da aplicação, fazendo conexão (mas não necessariamente) com a camada View.

A próxima camada é a de Template. Nela é onde os dados vão ser apresentados no browser. Esta camada consiste basicamente de arquivos .html com algumas funcionalidades que o Django fornece para apresentar os dados vindos da camada View. Essas funcionalidades são expressões, envolvidas em chaves.

Existem três tipos de expressões. A primeira delas é o {% %}, que permite executar comandos do python, como o for eachs e o ifs, e outras funcionalidades do próprio sistema de templates do Django.

A outra expressão é o {{ }}, ele é usado para acessar variáveis e mostrá-las na tela. Simples assim.

E a última expressão é uma variação da anterior, que é simplesmente um filtro representado pelo pipe. No exemplo mostrado é aplicado um filtro de data na variável usuario.data_de_nascimento. Há diversos filtros disponíveis, você pode conferir mais delas aqui.

E por fim vem a camada de View. Nela é onde as informações dos templates são tratadas. Existem dois tipos de views, as baseadas em função e as baseadas em classes.

As view baseadas em função(FBV) são funções normais do python, recebem um parâmetro obrigatório, o request, tem sua lógica dentro de si e retornam as informações necessárias para renderizar no template.

Nesta função é criado um dicionário context, nela irá conter as informações para ser passadas para o template. Dentro do context é feita uma consulta para retornar todos os usuários e por fim, na função render, é passado o próprio request, o template que vai ser direcionado as informações do context e o context em si.

E as views baseadas em classes(CBV) são classes que o Django genericas que abstraem a lógica das FBVs.

Com CBVs você sobre precisa dizer o model e o template que o Django faz a mágica.

Particularmente, eu prefiro as FBVs porque dão mais liberdade para fazer as regras de negócio mas, se não for uma lógica muito complexa, uma CBVs não vai fazer mal.

Nesse post, vimos a importância de uma arquitetura bem estruturada, o model de arquitetura que o Django adota e detalhamos as responsabilidades de suas camadas.

Flask vs Django — Rotas

Renato Lelis — Thu, 02 Jan 2020 18:16:06 +0000

Todo framework web (ou quase todos, não cheguei a trabalhar com todos) tem seu meio de fazer rotas entre suas função e as requisições do que vem do cliente. Nessas rotas também é possível configurar o método HTTP, onde uma rota /user com o método GET irá gerar um resultado diferente da rota /user com o método DELETE.

No modelo de arquitetura REST, os métodos HTTP têm semântica. Nele é recomendado que o método GET seja usado para consultas, o método POST para inserir informações, o PUT para atualizar e o DELETE para deletar. O REST determina outras boas práticas mas elas não vem ao caso agora.

No Django, as rotas são criadas num arquivo chamado urls.py, numa lista chamada urlpatterns.

Essa lista recebe a função path(), onde é passado a rota e qual a função do módulo views.py irá ser chamada.

No caso do Flask, um decorator é usado para criar as rotas.

É o mesmo princípio usado no Django, cada função recebe um decorator, app.routes, onde é passado sua rota.

A diferença aqui, é que o Django faz isso em arquivos separados e o Flask consegue fazer em um arquivo só (na verdade o Flask permite criar uma aplicação em um único arquivo se você quiser).

Outra grande diferença é o segundo argumento no decorator do Flask. Nele nós passamos uma lista de métodos HTTP e quando essa rota for chamada, dependendo do método, uma função diferente é chamada.

No exemplo acima, a rota é a mesma mas os métodos são diferentes, separando as funções que vão ser chamadas.

No Django, a diferenciação de métodos HTTP deve ser feita dentro da função chamada pela rota.

Com isso, sempre que houver a necessidade de alteração em alguma lógica de inserção ou de busca, a alteração vai acontecer em uma única função. Isso deixa a manutenção do código mais engessada.

Enquanto o Flask oferece mais flexibilidade e simplicidade nas rotas, o Django oferece mais velocidade na prototipagem (class based views for the win!) e uma arquitetura bem definida, embora obrigue o desenvolvedor a usar suas convenções.

Conectando o PostgreSQL com Django no Ubuntu

Renato Lelis — Thu, 02 Jan 2020 17:53:35 +0000

Fazer a conexão entre o django e o Postgres não é uma tarefa difícil mas se tratando de Linux, você vai precisar digitar algumas linhas de comando para fazer a instalação desse SGBD.
Instalando o PostgreSQL

Para começar, você precisa adicionar o repositório apt do Postgres ao seu sistema. Comece importando a chave GPG para os pacotes do Postgres com os seguintes comandos:

sudo apt-get install wget ca-certificateswget — quiet -0 — https://postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -

Agora adicione o repositorio no seu sistema

sudo sh -c ‘echo “deb http://apt.postgresql.org/pub/repos/apt/ `lsb_release -cs` -pgdg main” >> /etc/apt/sources.list.d/pgdg.list’

Sim eu sei, são comandos muito grandes, então não tenha vergonha e copie e cole no seu terminal ;).

Agora para finalmente instalar o Postgres, digite (ou copie) os seguintes comandos:

sudo apt-get updatesudo apt-get install postgresql postgresql-contrib

E pronto, depois disso o Postgres já deve estar instalado na sua maquina.

Criando o banco de dados

Para criar um banco de dados dentro do Postgres, primeiro conecte-se ao Postgres:

sudo su — postgrespsql

Crie um usuário e senha para seu banco:

CREATE USER 'root' WITH PASSWORD 'root';

Substitua o nome e senha root para qual você desejar.

Não se esqueça de colocar o ponto-e-vírgula no final de todo comando que digitar.

Agora crie o banco em si:

CREATE DATABASE django_postegres WITH OWNER root;

Esse comando vai criar o banco de dados e vai dar permissões para o usuário que você criou no passo anterior.

Digite \q e em seguida exit para sair do postgres

Conectando com o Django

Com o Postgres instalado e com as informações de usuário, senha e banco de dados, basta instalar o pacote do postgres via pip.

pip install psycopg2-binary

Agora vá no settings.py do seu projeto django para editar o dicionário DATABASES. Antes assim:

DATABASES = {   
    'default': {        
    'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
    }
}

Agora assim:

DATABASES = {
    'default': {
       'ENGINE': 'django.db.backends.postgresql_psycopg2',
       'NAME': 'django_postgres',
       'USER': 'root',
       'PASSWORD': 'root',
       'HOST': 'localhost',
       'PORT': 5432
      }
   }

A ENGINE indica qual driver vai ser usado para conectar com o banco de dados. No nosso caso vai ser o que veio com o psycopg2. O NAME vai ser o nome do banco de dados que foi criado. O USER vai ser o nome do usuário com permissões sobre nosso banco. O PASSWORD é a senha do usuário. O HOST é onde o banco está hospedado, no nosso caso está local, então será o localhost. E o PORT será a padrão do Postgres, a 5432.
Migrações

Depois disso tudo basta criar e aplicar suas migrações:

python manage.py makemigrations

python manage.py migrate

Conclusão

Deu para ver que esse processo não é dificil, só um pouco trabalhoso por causa dos comandos longos do linux mas nada que não se possa pegar prática.

Referências:

https://tecadmin.net/install-postgresql-server-on-ubuntu/

https://medium.com/@lucas_souto/integrando-django-com-postgresql-58b3520ddf6e