Dando sequencia ao tutorial, vamos agora detalhar e entender para que serve o arquivo settings.py. Se você não leu o post anterior, de uma pausa e confira: Destrinchando o Django – Startproject
O código do tutorial pode ser encontrado em: https://github.com/fernandovalente/django-tutorial
O objetivo desse post é te dar um norte e fazer você saber para que cada item dentro do settings.py serve. Em vários momentos você vai ler algo como “vamos nos aprofundar nesse assunto mais para frente”, mas fique calmo, vai dar tudo certo!
O arquivo settings (ou arquivo de configuração) é o coração do seu projeto. Nele vamos adicionar as configurações de banco de dados, arquivo estáticos e indicar o caminho base para as “medias”. Até a versão 1.6 o arquivo settings.py vinha com uma quantidade significativa de informações, o que causava uma grande confusão para desenvolvedores iniciantes no framework. A partir da versão 1.7, o arquivo de configuração reduziu bastante em número de linhas mas ainda precisamos ter uma atenção e um cuidado especial com o settings.
Preparar o código para rodar em máquinas diferentes, em servidores de desenvolvimento, homologação e produção pode ser uma tremenda dor de cabeça se você não pensar nisso desde o início. Como dito anteriormente, é no arquivo settings.py que adicionamos as informações de banco etc.
Digamos que você irá utilizar o MySQL* sem seu projeto. Certamente a senha e usuário que você usa em sua configuração local é diferente da configuração local do outro desenvolvedor que trabalha com você e certamente é diferente das configurações dos ambiente de desenvolvimento etc. Existe algumas soluções para isso mas, na minha opinião, a melhor e mais elegante é utilizar o Python Decouple.
Github do projeto Python Decouple: http://bit.ly/1Pxkg43
Instalação e configuração:
# Lembre de fazer a instalação dentro de sua virtualenv $ pip install python-decouple
Após a Instalação, vá na raiz do seu projeto e crie um arquivo chamado .env
$ touch .env
Como dito anteriormente, várias configurações serão diferentes em diferentes ambientes, e é nesse momento que vamos ajustar essas configurações. Pacote instalado, arquivo criado? Vamos voltar para o settings.py e adicionar apenas duas configurações no momento.
from decouple import config
# separe a sua SECRET_KEY pois vamos usar ela posteriormente SECRET_KEY = config(‘SECRET_KEY’)
DEBUG = config(‘DEBUG’, default=False, cast=bool)
Depois de adicionado o import e atualizado essas duas linhas, teste rodar dua aplicação e ver o que acontece
$ python manage.py runserver 0.0.0.0:8000
SECRET_KEY = config(‘SECRET_KEY’) File “/Users/nandovalente/Documents/Projects/django-tutorial/env/lib/python3.4/site-packages/decouple.py”, line 198, in __call__ return self.config(*args, **kwargs) File “/Users/nandovalente/Documents/Projects/django-tutorial/env/lib/python3.4/site-packages/decouple.py”, line 77, in __call__ return self.get(*args, **kwargs) File “/Users/nandovalente/Documents/Projects/django-tutorial/env/lib/python3.4/site-packages/decouple.py”, line 64, in get raise UndefinedValueError(‘%s option not found and default value was not defined.’ % option) decouple.UndefinedValueError: SECRET_KEY option not found and default value was not defined.
Deu um erro certo? Que bom, esse era o esperado pois não existe mais uma SECRET_KEY no settings da sua aplicação. Vamos fazer a aplicação rodar agora… Abra o arquivo .env que criamos:
[settings] SECRET_KEY='cole aqui a SECRET_KEY que você separou' DEBUG=True
Se você não se parou a SECRET_KEY calma, não entre em pânico! Gere uma nova no link a seguir e tudo estará resolvido: http://bit.ly/1aCntjt.
Além da SECRET_KEY, adicionamos o DEBUG. Em nosso arquivo settings, vamos adicionar a seguinte linha:
DEBUG = config(‘DEBUG’, default=False, cast=bool)
Voltando para o .env:
DEBUG=True
Agora volte para o terminal e rode bote sua aplicação para rodar:
$ python manage.py runserver 0.0.0.0:8000
Se você fez tudo certo, você verá essa linda tela:
Seu primeiro site em Django está rodando! Parabéns! 🙂
Vamos continuar?
O preenchimento do allowed hosts é uma medida de segurança! Para configurar esse item você deve passar uma lista de strings contendo os nomes do host ou domínios que sua aplicação irá servir.
ALLOWED_HOSTS = [‘localhost’, ‘127.0.0.1’]
Como dito anteriormente, no momento que você colocar em produção/homologação, você utilizará outras configurações, por exemplo:
ALLOWED_HOSTS = ['.example.com', '.example.com.']
O Django permite que você trabalhe de forma modular e faz isso com louvor. O que você precisa saber nesse momento é que toda nova app criada deverá ser adicionada aqui nessa lista.
A installed apps é responsável foi informar quais apps seu projeto está usando. Vamos nos aprofundar mais sobre isso no tópico de criação e administração de apps, que será o próximo da série.
# Application definition
INSTALLED_APPS = (
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
)Cada componente middleware é responsável por fazer alguma função específica. Por exemplo, o Django inclui um componente middleware, AuthenticationMiddleware, que associa os usuários com solicitações usando sessões. Por padrão, algumas middleware estão presentes no settings sem e todas são de extrema importância para nosso projeto.
MIDDLEWARE_CLASSES = ( ‘django.contrib.sessions.middleware.SessionMiddleware’, ‘django.middleware.common.CommonMiddleware’, ‘django.middleware.csrf.CsrfViewMiddleware’, ‘django.contrib.auth.middleware.AuthenticationMiddleware’, ‘django.contrib.auth.middleware.SessionAuthenticationMiddleware’, ‘django.contrib.messages.middleware.MessageMiddleware’, ‘django.middleware.clickjacking.XFrameOptionsMiddleware’, ‘django.middleware.security.SecurityMiddleware’, )
Para ficar mais claro onde exatamente o middleware atua (o nome já explica muita coisa), veja a imagem abaixo:
É possível fazer muita coisa legal, mas vamos nos contentar em utilizar as existentes no Django. Futuramente, quem sabe, posso fazer um post explicando como criar sua própria middleware.
Por padrão, ao dar start em sua aplicação, o Django define o ROOT_URLCONF para você. O caminho padrão para suas URLs é composto pelo nome da seu projeto.urls.
ROOT_URLCONF = ‘tutorial.urls’
Podemos mudar isso? Sim, mas… Se você não tiver uma boa justificativa para isso, não recomendo. Existe uma forma bem simples de separar suas URLs mantendo esse arquivo principal bem limpo e organizado. Veremos no próximo post mais detalhes como as apps funcionam no Django e vamos colocar a mão mais profundamente nas URLs do Django.
No Django 1.8 o sistema de templates sofreu algumas mudanças. Podemos notar de cara isso dentro do nosso settings. Quem já trabalhou com versões anteriores perceberá que a configuração ficou um pouco maior na versão 1.8:
TEMPLATES = [
{
‘BACKEND’: ‘django.template.backends.django.DjangoTemplates’,
‘DIRS’: [],
‘APP_DIRS’: True,
‘OPTIONS’: {
‘context_processors’: [
‘django.template.context_processors.debug’,
‘django.template.context_processors.request’,
‘django.contrib.auth.context_processors.auth’,
‘django.contrib.messages.context_processors.messages’,
],
},
},
]Eu sei que você já deve estar cansado de ler isso, mas… Vamos nos aprofundar mais nos templates um pouco mais para frente.
Esse assunto não vamos pular! O próprio nome já fala muita coisa, mas… É aqui que colocamos as configurações do nosso banco de dados.
Atualmente o Django tem suporte a vários bancos de dados, mas não todos. Por padrão o settings define o SQLite para que possamos dar início ao nosso projeto configurando o mínimo possível, mas podemos usar o MySQL, PostgreSQL (meu favorito por sinal), algumas versões do Oracle e por ai vai.
Vamos começar usando o sqlite nesse início e, posteriormente, vamos usar o Mysql e o PostgreSQL.
DATABASES = {
‘default’: {
‘ENGINE’: ‘django.db.backends.sqlite3’,
‘NAME’: os.path.join(BASE_DIR, ‘db.sqlite3’),
}
}Por padrão o Django da suporte a várias línguas, inclusive o português (graças a nossa comunidade maravilhosa).
LANGUAGE_CODE = 'pt-br'
TIME_ZONE = ‘UTC’
USE_I18N = True
USE_L10N = True
USE_TZ = True
É aqui que informamos onde estão os nosso arquivos estáticos e para onde vão as mídias durante um upload de foto e/ou arquivo. Vamos nos contentar com essas informações no momento e voltaremos aqui posteriormente.
E chegamos ao fim do nosso settings.py! Se você chegou aqui com o sentimento de que não aprendeu muita coisa, calma! Como falei lá no início, aguarde e confie!
O mais importante agora é que você conhece o settings e, mesmo que não saiba afundo tudo sobre ele, você sabe para que serve cada coisa existente nele e era esse meu objetivo.
O próximo “Destrinchando o Django” vamos criar uma aplicação, configurar nossas rotas, criar nossa primeira view, nosso primeiro model nosso e nosso primeiro teste!
Abraços e até o próximo post!
Atuante na área de desenvolvimento web desde 2007 prestando serviços para corporações da área da saúde, educação, tecnologia e pesquisa, jornalismo e entretenimento. Além de apaixonado pelo que faz, é aficionado por Python e tecnologia. Membro da Python Software Foundation, Python Brasil e Doador do Django Project.
You must be logged in to post a comment.
