Django - Processadores de contexto

Sempre que vamos processar um template por meio de uma view precisamos especificar diversas variáveis em todas as views. Por exemplo, é uma boa prática especificar as urls completas nos templates ao invés de só o caminho relativo. Para isso, precisaríamos recuperar o endereço base do seu site em todas as views manualmente. Ou então, dados processados relativos ao usuário atual. Teríamos que, na melhor das hipóteses, chamar um mesmo método em todas as views. Não seria muito mais fácil especificar isso uma vez só e o django carregar isso como valores "globais" em suas views? Pois bem, é exatamente isso que os processadores de contexto fazem.

Os processadores de contexto te permitem especificar diversas variáveis que são definidas automaticamente em todos os contextos automaticamente - sem precisar ficar as especificando em cada chamada ao método render_to_response(). Mesmo que os valores armazenados por essas variáveis necessitem ser processados para serem gerados, ou recuperados de um banco de dados.

Django admin: inlines obrigatórios

Um problema recorrente nos projetos em que trabalhei com Django foi tornar inlines obrigatórios no admin. Fiz diversas gambiarras, conforme a situação,  para tentar resolver isso, mas nunca havia encontrado uma forma satisfatória de resolver esse problema, até agora. Pois sabemos como os usuários são: você avisa que se não fizer de tal modo vai dar problema. O que acontece? Eles ignoram, isso causa um monte de problema e, claro, no final nós desenvolvedores somos os culpados. Enfim.

Depois de bastante tempo de procura, acabei caindo nesta discussão sobre o assunto que me levou a um snippet, um fragmento de código, que resolve o problema. O código a seguir foi obtido aqui. Ele altera o comportamento padrão da classe BaseInlineFormSet que é usada pelo admin para montar seus formulários, fazendo com que obrigue o usuário a salvar ao menos um inline.

Como gerar sitemaps a partir dos modelos do Django

Antes de qualquer coisa, o que é um sitemap?

É um formato de arquivo XML, definido aqui, que possui links para as páginas do seu site. Seu objetivo é facilitar o trabalho dos crawlers (bots de sistemas de busca que varrem os sites para indexação de conteúdo). Um dos critérios principais que todo crawler usa é não dar muita relevância para páginas muito profundas do seu site, ou melhor, páginas em que o usuário deve clicar em muitos links para chegar. Para essas páginas o sitemap é especialmente importante, pois ele ajuda a dar uma relevância muito maior a essas páginas, que poderiam ser consideradas pouco significantes para o crawler.

Sitemaps também facilitam muito o trabalho dos crawlers, os quais vão poder indexar um volume grande de páginas de seu site rapidamente, pois não vão precisar ficar varrendo página por página em busca de links. Porém, para sites muito grandes é aconselhável fazer múltiplos sitemaps, divididos em seções, para que não haja muitos links em uma página.

Sites com vários idiomas em Django - Rosetta

Já faz algum tempo que entrei em contato com um pacote chamado Rosetta. Mas não mexi com ele. Fiz tudo que precisava no sistema e ficou esquecido lá. Só agora que fui trabalhar com ele de novo. E o achei que interessante.

Como o nome sugere, o Rosetta serve para tradução em vários idiomas. Como ele faz a tradução? Ele gerencia os arquivos de tradução do django. O que deixa tudo muito mais organizado e fácil de traduzir, pois tudo que você vai precisar fazer é preencher os campos para tradução no admin do Rosetta. Bem mais simples que lidar diretamente com os arquivos de idioma do Django, não é mesmo?

Antes de usarmos o Rosetta, precisamos gerar os arquivos de tradução do Django. Isso pode ser feito automaticamente. Primeiro, temos que configurar algumas coisas no settings.py. Pra começar temos que ativar o módulo i18n, que é o módulo de internacionalização do Django. Pelo que notei até na versão 1.4 do Django já vem ativado, caso não, ative-o no seu settings.py:

USE_I18N = True

Django - Como ocultar condicionalmente inlines no admin?

Esta semana precisei fazer uma coisa no admin do Django que fazia tempo que tentava e não conseguia: ocultar os inlines condicionalmente. Ou melhor, queria só exibi-los para objetos existentes e ocultá-los para um objeto sendo criado. Ou qualquer outra condição que surgisse, até então, só exceções e decepções.
Sempre soube que é possível de ocultar os campos, mas e os benditos inlines? Todas as soluções que encontrei até hoje não resolviam isso. Ajudavam bastante, ou eram tão complicadas, que eram inviáveis de serem colocadas em prática. O que me salvou foi esta dica aqui que me deu as orientações de que precisava.

Django - Como obter a URL atual

Este é mais um post rápido. Porém, sobre uma coisa que sempre procurei por aí e nunca encontrei uma boa resposta. Sempre tinha que fazer alguma gambiarra. Mas esses tempos negros se foram. Finalmente, sem querer, encontrei a resposta para essa pergunta. É claro que também vou listar as soluções gambiarrentas, pois nunca se sabe quando uma delas pode vir a ser útil.

Django: miudagens úteis

Sabe aquelas miudagens que temos que fazer com frequência, mas não tanta frequência assim? Claro que tempo o suficiente para não lembrarmos direito como fazer, ter que pesquisar quase tudo de novo, perder aquele baita tempo pra chegar num "Nossa! Não lembrava que era tão simples."?

Bem, é esse tipo de miudagem que vou listar neste post. Para montá-lo fui adicionando a ele todas as miudagens de que precisei várias nos últimos tempos e acabei tendo de pesquisar de novo para relembrar como fazer. Tem mais algumas que adicionei por serem coisas miúdas, mas difíceis de encontrar a solução por aí.

Como configurar o django-celery

Aqui vou explicar como instalar o django-celery, seus requisitos e como configurá-lo. Pois, para variar, foi necessário consultar uma infinidade de fontes para aproveitar uma linha ou duas de cada uma.  Sim, isso torra o ** é chato demais e perdemos muito tempo. =/
Comecemos.

O que é o django-celery?

O django-celery é um pacote para o django para fornecer ao django as funcionalidades do Celery. O qual se trata de uma ferramenta distribuída para gerenciamento de tarefas.

Retirado do site do Celery:

O Celery é uma ferramenta para gerenciamento de fila de tarefas assíncronas baseado em passagem de mensagens distribuídas. Seu foco é em operações em tempo real, mas também suporta agendamento de tarefas.
Suas unidades de execução, chamadas de "tarefas", são executadas concorrentemente em um ou mais servidores usando multiprocessamento, Eventlet, ou gevent. As tarefas podem ser executadas de forma assíncrona (no plano de fundo) ou de forma síncrona (esperar até que esteja pronta).

Celery é escrito em Python, mas seus protocolos podem ser implementados em qualquer linguagem. Ele também pode trabalhar com outras linguagens usando "webhooks". Sem contar que há o RCelery feito para Ruby e funciona como cliente PHP.
O gerenciador de mensagens padrão/recomendado é o RabbitMQ, mas fornece suporte para Redis, MongoDB, Beanstalk, Amazon SQS, CouchDB e bancos de dados (usa SQLAlchemy ou o Django ORM).

Em miúdos: é um anacron com ferramentas para trabalho distribuído e integrável a várias ferramentas.