Django Brasil


Blog da Django Brasil


Feeds RSS

Arquivo

Se deseja publicar uma notícia ou artigo neste Weblog, ou tem alguma sugestão de algum assunto que poderia ser publicado por aqui, entre em contato.

Arquivo de Janeiro de 2009

O que é o django.contrib?

Publicado em 20/01/2009 às 15h16

Jacob Kaplan-Moss adicionou em seu blog um post interessante com algumas considerações sobre o django-contrib. Embora não seja uma declaração oficial da equipe de desenvolvimento do Django, é um texto bem interessante e lança alguma luz sobre o que podemos esperar do futuro do framework. Boa leitura!

O que é o Django Contrib?

por Jacob Kaplan-Moss

tradução de Walter Cruz

Já que é uma pergunta recorrente, eu pensei em gastar um tempinho escrevendo minhas idéias a respeito do que o django.contrib realmente é, e o que realmente significa a inclusão de um pacote nele.

Essa é apenas minha opnião pessoal — de fato, é por isso que eu postei aqui ao invés de adicionar esse conteúdo na documentação oficial do Django. Porém, a maior parte do core team do Django discutiu esse tópico extensivamente na DjangoCon, então eu estou bem seguro que há um certo consenso sobre essas idéias.

Em resumo, o django.contrib contém implementações opcionais e padronizadas de padrões comuns. Isso é:

  • Opcional: pacotes do contrib devem ser removíveis. Você deve ser capaz de executar um rm -rf django/contrib e o Django não deve quebrar.

Leitores astutos vão perceber que o django.contrib.contenttypes viola essa regra. Eu penso que isso deveria ser considerado um bug.

Com isso, os pacotes do django.contrib idealmente não devem ter "acesso especial" à qualquer coisa interna do Django — tudo o que um pacote do contrib faz deve ser possível de ser feito em um aplicativo externo. Novamente, leitores astutos irão notar que quebramos essas regras em alguns lugares, e, mais uma vez, isso deve ser considerado um bug.

  • Padronizadas: tudo no contrib precisa ser geralmente aceito como a Forma Correta de fazer algo pela grande maioria dos usuários.

django.contrib.sessions é um exemplo disso. Existem muitas formas de lidar com sessções, mas a forma que o Django faz — um identificador de sessão opaco no cookie, com todos os dados armazenados no backend — é geralmente aceito como uma ótima prática. Sim, existem outros meios de implementar sessões — posso citar, por exemplo, cookies assinados — mas a técnica usada pelo django.contrib.sessions geralmente funciona para a maior parte dos usuários.

  • Padrões Comuns: pacotes no contrib devem resolver problemas encontrados frequentemente por desenvolvedores web comuns. Então, eu gostaria de argumentar contra a inclusão de algo como o django-reversion. Ele é muito legal e eu o uso, mas o rastreamento de dados versionados nessa granularidade não é algo necessário na vasta maioria dos sites.

Bons pacotes do contrib devem tratar questões que não sejam triviais, que sejam propensas a muita discussão, e que sejam difíceis de fazer do modo certo para o caso comum. Queremos evitar que as pessoas precisem decidir entre dezessete frameworks de sessões diferentes, por exemplo.

Sobre o django.contrib.gis: ele não é exatamente um padrão comum, mas se você está lidando com dados geográficos, construindo em cima de ferramentas GIS existentes como o PostGIS e o GDAL, ele é ambos: o padrão comum e a melhor prática. Você poderia dizer que o django.contrib.gis implementa um padrão comum para uma classe menor de usuários, eu suponho. Mais importante, porém, é algo complicado de ter funcionando corretamente, então há um grande valor em te-lo funcionando.

É claro, existe um valor de marketing em ter algo no contrib. Certamente ajuda as Relações Públicas dizer que o "Django vem com suporte a GIS." Está na moda desdenhar das Relações Públicas no mundo opensource, mas eu seria falso em dizer que eu não uso o poder do contrib como uma ferramenta de marketing. Eu certamente o faço, e não tenho reservas em faze-lo.

Mas há um problema em trazer algo para o núcleo: isso impede inovação. Assim que nós "abençoamos" um pacote do contrib, reduzimos drastricamente o ímpeto de escrever bibliotecas competitivas. Assim, um bom pacote do contrib deve ter consenso geral, e deve ser bem maduro. É por isso que uma biblioteca de evolução de esquemas não estará presente no Django 1.1 a despeito de termos três ou quatro alternativas viáveis. Nenhuma dessas opções é claramente melhor, e todas estão evoluindo muito rápido. Devemos esperar para "aprovar" uma biblioteca até que tenhamos certeza de qual é a certa..

Outra desvantagem para a inclusão de pacotes no contrib é o acoplamento das funcionalidades dos pacotes com o ciclo de lançamentos do Django. Um pacote pequeno como o django-tagging pode adicionar funcionalidades rapidamente; limitar releases a cada seis ou nove meses iria retardar a sua divulgação enquanto usuários esperam por novas versões do Django para serem capazes de atualizar o pacote.

A inclusão de um pacote no contrib é também uma promessa de suporte futuro: nada seria pior que ter de remover um pacote do contrib em uma versão futura — queremos adicionar funcionalidade, não retirá-las! Porém, a adição de novos pacotes no contrib significa mais trabalho para os committers, então, um novo pacote realmente precisa trazer junto um novo contribuidor. Idealmente, um grupo de novos contribuidores: ter parte do código na mão de apenas um contribuidor não é uma boa idéia..

Django no Washington Post

Publicado em 19/01/2009 às 18h53

Uma das perguntas que nós fazemos na escolha de um framework (principalmente os sysadmins!) é: ele aguenta o tranco? Sempre dá mais confiança saber que o framework que escolhemos foi usado em algum grande projeto.

Peter Harkins publicou em seu blog uma lista das aplicações no Washington Post que foram criadas em Django. Entre os aplicativos, bastate coisa desenvolvida para a campanha a presidência dos Estados Unidos no ano passado, um aplicativo de receitas, com um widget de receita do dia para ser incluído em seu blog, e muito mais.

No blog do autor você pode encontrar detalhes de cada uma das aplicações.

Suporte a Agregação no Django 1.1

Publicado em 15/01/2009 às 17h25

Hoje, o Django ganhou suporte a agregação, na revisão 9742 do SVN. O código foi adicionado por Russ Magee. Basicamente, o código adiciona dois métodos aos Querysets: annotate() e aggregate() .

Um pequeno problema com a combinação Python 2.5 + SQLite no Windows ainda persiste, mas já está sendo trabalhado.

No e-mail enviado para a lista Django Developers, Russ agradece a Nicolas Lara que fez a primeira implementação das agregações como parte do Google Summer of Code 2008 .

A documentação sobre a agregação já está disponível em: http://docs.djangoproject.com/en/dev/topics/db/aggregation

Anunciada segunda edição do Django Book

Publicado em 09/01/2009 às 18h24

Adrian Holovaty anunciou em seu blog que está trabalhando na segunda edição do Django Book.

A primeira edição que foi escrita em parceria com Jacob Kaplan-Moss cobria a versão 0.96 do Django, e muitos exemplos não funcionam mais com a versão 1.0. A nova versão do livro será baseada no Django 1.0, e como o Django 1.0 se preocupa com a retro-compatibilidade, ele deve permanecer atualizado por mais tempo.

O livro não será apenas uma atualização do anterior: contará com a reestruturação de conteúdo e até mesmo com a edição de novos capítulos. É possível ler algumas prévias online (em inglês) em http://www.djangobook.com/en/2.0/. A versão impressa será publicada pela Apress.

Mais informações em http://www.holovaty.com/blog/archive/2009/01/09/0133


Hospedado por APyB. Django Brasil é a comunidade brasileira de usuários do framework web Django. Django é uma marca registrada de Lawrence Journal-World.