Pesquisar este blog

segunda-feira, 10 de dezembro de 2007

Design Patterns com Django ^^, e outras dicas

Olá! Hoje é um dia especial.
- "Especial por quê?" - diz o Joãozinho!
- Pirralho lazarento, especial porque a figura de minha pessoa vai falar um pouquinho sobre decisões de design que eu uso em meus aplicativos, assim como um ou dois truques legais, que eu també uso.
De qualquer forma, melhor começar com o pé direito, não é mesmo? Então vamos lá a um momento angelical (depois eu explico o por que do nome disso ^^).

Momento Angelical
Frase do Dia: Quem não escuta conselho, escuta "coitado!".
E assim falou a nossa filósofa cafúcia ^^.

Profundo não? Uma verdadeira tigela de mingal! Rrsrsrs, mas tem um fundo de verdade nisso aí. De qualquer forma, não sei já falei de Django para as vossas ilustres pessoas. Se já falei, "aleluia!" estou produtivo. Se não, se pergunte, caso você seja um desenvolvedor, se pergunte no âmago de seu ser por quê diabos vc não sabe do que estou falando! Um absurdo, criatura! Django é o framework WEB escrito em python mais quente do momento(quem falar em Plone/Zope, leva pedrada pela falta de cortesia). Leva padrões de desenvolvimento como DRY, KISS, MVT(C?), Ajax, Json, ORM, OO, e um monte de siglas de gente grande bem a sério. Esse post é PARA QUEM JÁ CONHECE DJANGO!!!.

Oh My God, they killed Kenny! You bastards! rsrsrs Pois é, esse é um post para público específico e especificado. Depois coloco um tuto aqui, mas esse depois não é agora.
De qualquer forma, eu vou falar de uma solução legal que pode ser acoplada no seu aplicativo django, e uma sugestão de organização de projeto. Algo que eu faço aqui e me agrada.

A solução facila criar decoradores que aceitam argumentos de uma forma fácil. A grande ironia da coisa é que se usa um decorador para fazê-lo. Vou logo avisando que essa solução não é minha e eu não lembro de onde peguei. De qualquer forma, se alguém achar o link e quiser postar aqui, está bem vindo.

A solução consiste em se criar este pequeno decorador:

decorator_with_args = lambda decorator: lambda *args, **kwargs: lambda func: decorator(func, *args, **kwargs)

Eu acho uma solução legal. Veja, na pior das hipóteses, funciona a contento! Eis aqui um exemplo de utilização:


@decorator_with_args
def notify_admin(view,message):
def some_func(request, *args, **kwargs):
pass #... envia a mensagem ou coisa do genero
return some_func


Esse decorador tem me evitado muito ninjutsu pythoniano.

Quanto a solução de design, estou meio sonolento, e por isso, vou ser bem direto. Ela consiste em criar um aplicativo controle, um aplicativo accounts e um package _lib para todo projeto que você fizer(dependendo das suas necessidades). O primeiro consiste em ser um aplicativo para "coisas". Você coloca views que não se encaixam em outros aplicativos nele. Inclusive, views que, por serem bem específicas, não merecem um aplicativo só para elas. Colocar templateTags e filters nesse aplicativo facilita as coisas, assim como o UserProfile(profile do usuário) e UserData(dados extras do usuário, como endereço, etc. Tenha-o linkado no Profile), que também "devem" ficar nele. O accounts é basicamente o que ele diz que é, serve para o usuário bulir na sua conta. Eu tenho criado gosto por ter um app desses nos meus projetos. Ele facilita bastante as coisas. Um negócio que fica legal também é criar um sistema de mensagens entre usuários nesse app. Dá para linkar tudo no mesmo canto; bastante prático.
Por ultimo, o _lib. Nele eu coloco bibliotecas/funções/classes que devam ser compartilhadas entre todos os aplicativos. Definir errorLists customizados nele, por exemplo, fica bem legal.

Rsrsrs, é, cansei...ops, Acabei! :D! Espero que este post tenha ficado interessante, ou não >: D. Rrsrsr, intelegível, pronto! Espero que tenha ficado intelegível! ^^ Abraço a todos.

Um comentário: