Publicações com a etiqueta "django"
Pré-inicializando formulários de um FormWizard
Se você precisa pré-inicializar dados de formulários num FormWizard do Django, você consegue da seguinte forma:
my_wizard = MyWizard(
[StepOneForm, StepTwoForm],
initial={
1: {field_x: data, field_y: data, ...},
2: {field_x: data, field_y: data, ...},
...
}
)
Certo? Ok, mas e se eu quiser inserir estes dados dinamicamente, de acordo com o usuário logado no site?
A forma que eu encontrei de fazer isso foi sobrescrevendo alguns métodos da classe FormWizard. Veja um exemplo:
from django.contrib.formtools.wizard import FormWizard
class MyWizard(FormWizard):
def parse_params(self, request, *args, **kwargs):
self.user_data = {
'first_name' = request.user.first_name,
'last_name' = request.user.last_name
}
def get_form(self, step, data=None):
if step == 1:
return self.form_list[1](data, prefix=self.prefix_for_step(1),
initial=self.user_data)
else:
super(MyWizard, self).get_form(step, data)
...
Não conhece o form wizard do Django? Leia mais a respeito na documentação oficial do utilitário.
Diário 0.2 out! The Alexandros Grigoropoulos's Diary Release
Today was released the Diário version 0.2, blog application for Django projects, packaged from revision 181 in Subversion.
New in version 0.2:
- Django 1.0.X compatible;
- Support to ping weblog directories (issue #11);
- Changed license to LGPLv3 (issue #36);
- Some code refactoring;
- Removed deprecated features;
- Many bug fixes;
- Other enhancements.
Diário 0.2 too will be packaged to Debian by Lincoln Sousa and be available in main Debian repository.
Help us to improve Diário! See the Roadmap for version 0.3. Thanks to everyone who made this release possible!
This version is a tribute to Alexandros Grigoropoulos, 15-year-old boy, libertarian, murdered by greek police in last week (2008-12-06).
Selecionando por padrão o site corrente num ManyToManyField(Site, ...)
Quem utiliza a django.contrib.sites do Django pode gostar desta dica.
Para quem não conhece, a aplicação sites permite você compartilhar um model com vários outros sites (ou projetos), podendo ter conteúdos iguais (ou em parte) sem redundância, utilizando uma mesma tabela.
No Django 1.0, quando há apenas uma opção para escolha numa ManyToManyField, ela não é selecionada por padrão quando o campo é obrigatório. Antes da versão 1.0 isso não era problema, mas me incomodava o fato de que quando eu tinha mais de uma entrada no model Site, eu deveria escolher o site ao qual eu estava acessando.
Seria interessante pré-selecionar por padrão o site corrente, quando o mesmo é obrigatório e você está acessando sua interface administrativa.
Quando tentei pela última vez fazer isso não obtive sucesso. A idéia era passar para o parâmetro default do ManyToManyField o valor de Site.objects.get_current(). Sem sucesso, não dei mais atenção a isso, mas com o Django 1.0, a cada vez que iria publicar algo neste blog, por exemplo, eu deveria selecionar o site semente.taurinus.org, mesmo sendo o único, a cada texto publicado.
Como todo bom preguiçoso, isso me frustava pois sempre esquecia de marcar o site para ser publicado, causando um erro de validação. Se isso acontece com você meu amigo, eis a solução:
+ from django.conf import settings @@ - publish_on = models.ManyToManyField(Site) + publish_on = models.ManyToManyField(Site, default=[settings.SITE_ID])
A solução acima já foi aplicada no Diário, aplicação para blog que este site faz uso.
Django Diário is now compatible with Django 1.0
Diário weblog application for Django is now compatible with Django 1.0.
After release candidate 1, Diário was broken because of comments refactoring. Apparently, everything works fine.
Special thanks to Rodrigo Pimentel to open an issue for this and for sending patch.
Now is close the eternal issues. :-P
Liberada a versão do Django candidata à 1.0!
Saiu a versão candidata à 1.0 do Django! Agora acredito que só serão aceitos correções de defeitos, atualizações de tradução e documentação.
Existe ainda um ticket (#8796) da django-l10n-portuguese, no roadmap da 1.0, para a atualização do arquivo POT de localização.
Falta apenas 10 strings a serem traduzidas, revisões e uma tarefa sugerida pelo Luciano Ramalho que pode ser encontrada na discussão http://groups.google.com/group/django-l10n-portuguese/browse_thread/thread/8c1c0460d19ccc27. Quem se interessar, envie suas sugestões para a lista de localização ou fique à vontade em anexar seus patchs no ticket #8796.
Confira também as notas de lançamento da versão candidata à 1.0. Note que ela ainda não é a versão definitiva e não é recomendada para o uso em produção, porém creio que não haverá nenhum incidente que atrasará seu lançamento.
Aplicação comments do Django refatorada
Boa notícia para os desenvolvedores Django! Ontem foi feita a refatoração da aplicação bult-in comments do Django (changeset 8557).
Dentre as mudanças, as que mais gostei são:
- Aquela idéia de FreeComment foi abandonada: agora existe somente um model Comment;
- foram adicionados os campos email e URL;
- e agora é documentado!
Detalhes de como atualizar seu código para o novo comments em http://docs.djangoproject.com/en/dev/ref/contrib/comments/upgrade/.
Se ainda não gosta desta aplicação, existe uma alternativa com suporte a threads: é o django-threadedcomments.
PyCon Rio: e lá vou eu...
Confirmado: estou indo para a PyConBrasil, edição Rio de Janeiro. O evento ocorrerá durante os dias 18, 19 e 20 de setembro. Estarei por lá nos dias 17 à 21.
Quem vai? Será que galera da Django Brasil estará em peso por lá para um encontro informal!?
Maiores informações, no site do evento: http://pyconbrasil.com.br/.
Tema do Django para GNOME
Eu utilizo no meu GNOME o tema Clearlooks acho que desde que ele foi lançado. Tentei utilizar outros, mas nunca me acostumei.
Depois que o grande pixel-artista Jader Rubini, fez um lindo fundo de tela para a comunidade Django Brasil, eu dei uma uma pequena personalizada no Clearlooks e o chamei de Django. E por que não? Tem as mesmas cores comumente utilizadas pelo Projeto Django.
Eu achei que o conjunto (fundo de tela, clearlooks e cores) ficou bonito e agradável. Dê uma olhada:
Minha área de trabalho.
Se gostou também, você pode obtê-los nos links abaixo:
- Tema: django-gnome-theme.tar.gz
- Fundo de tela: DjangoBrasil_Wallpapers_by_jaderubini.zip
Lista de discussão Django Apps
O Michael Elsdörfer criou a lista de discussão Django Apps. A idéia é utilizar a lista para suas próprias aplicações Django e isso possui, no mínimo, duas grandes vantagens:
- Se faz desnecessário a criação de uma lista de discussão para cada nova aplicação;
- Existe uma potencial possibilidade de outras pessoas, não necessariamente usuárias de suas aplicações, participarem das discussões com ótimas opiniões.
Eu não iria criar listas de discussões para minhas aplicações, uma vez que o número de discussões tenderia à zero e seria uma tarefa chata, mas, com isso, as aplicações Diário, Fleshin e Tube ganharam um local para discussão!
Então, quando precisar, já sabe onde pode discutir algo a respeito das aplicações citadas acima. Já adicionei o grupo de discussão nas páginas dos meus projetos no Google Code. Utilize o prefixo [diario], [fleshin] e [tube] no assunto das mensagens, como descrito na página inicial do grupo:
All messages should be prefixed with the application name in brackets. If the application name itself has the popular django prefix, it should be left off. E.g. use [tables] for django-tables.
Legibilidade e reaproveitamento de código na "URLConf"
É comum nas configurações de URL (URLconf) [1] do Django, patterns como este abaixo:
urlpatterns = patterns(
'django.views.generic.date_based',
(r'^(?P<year>\d{4})/(?P<month>[0-9]{2})/(?P<day>\d{1,2})/(?P<slug>[-\w]+)/$',
'object_detail', dict(info_dict, slug_field='slug', month_format='%m')),
(r'^(?P<year>\d{4})/(?P<month>[0-9]{2})/(?P<day>\d{1,2})/$',
'archive_day', dict(info_dict, month_format='%m')),
(r'^(?P<year>\d{4})/(?P<month>[0-9]{2})/$',
'archive_month', dict(info_dict, month_format='%m')),
(r'^(?P<year>\d{4})/$', 'archive_year', info_dict),
(r'^/?$', 'archive_index', dict(info_dict, num_latest=5)),
)
Apesar da modificação nas URLs serem raras, a legibilidade da forma acima, queira ou não, prejudica numa eventual manutenção e a probabilidade de ocorrer um erro aumenta.
Uma solução que ao meu ver facilita muito a leitura seria utilizando a função url(), como no código abaixo, retirado do django-fleshin:
photo_detail = url(
regex = '^(?P<album>[-\w]+)/(?P<slug>[-\w]+)/$',
view = 'fleshin.views.photo_detail',
kwargs = dict(photo_info_dict, slug_field='slug'),
name = 'fleshin-photo'
)
photo_list = url( # all photos + album list
regex = '^$',
view = 'django.views.generic.list_detail.object_list',
kwargs = dict(photo_info_dict, paginate_by=FLESHIN_NUM_LATEST,
extra_context={'album_list': Album.objects.all}),
name = 'fleshin-photo-list'
)
photo_album_list = url( # only photos in ``album``
regex = '^(?P<album>[-\w]+)/$',
view = 'fleshin.views.photo_list',
kwargs = dict(photo_info_dict, paginate_by=FLESHIN_NUM_LATEST),
name = 'fleshin-photo-album-list'
)
urlpatterns = patterns('', photo_detail, photo_list, photo_album_list)
Perceba também que a forma acima facilita a reutilização dos patterns pelo seu projeto, não ficando preso ao que foi definido no django-fleshin, reaproveitando, por exemplo, o mesmo padrão de URL para o detalhamento de uma Photo (photo_detail) e alterando o padrão para a listagem das mesmas (photo_list e photo_album_list).
| [1] | Geralmente encontrado em um arquivo de nome urls.py. |