O novo site do Deputado Fernando Mineiro proporciona uma maior interação entre os visitantes, possibilitada através de comentários em notícias, vídeos e galerias de fotos. O visitante pode ainda escrever um depoimento sobre o deputado ou inscrever-se para receber o boletim eletrônico ou as publicações impressas, que também estarão no site.
Outro ponto forte é a referência às redes sociais das quais o Deputado participa, como por exemplo Youtube, Orkut, Twitter e Flickr. (http://mineiropt.com.br/)
Leia essa entrada em seu contexto
original »
A Orangotoe, empresa que desenvolve portais em Curitiba está procurando prodígios da web para trabalhar em projetos como o Paraná Online e Banda B.
Mais informações no blog da empresa.
Arquivado como:django, tech Tagged: orangotoe, vaga 
Leia essa entrada em seu contexto
original »
Depois de muito não encontrar nada para postar aqui, e ter meus problemas todos sanados por artigos já escritos na internet. Encontrei algo útil quando fui instalar meu velho amigo framework Django com a biblioteca PIL assim como uma atualização da linguagem de programação Python, da versão 2.6.1 para versão 2.6.4.
Antes de mais nada o [...]
Leia essa entrada em seu contexto
original »
Neste artigo vamos criar uma nova funcionalidade na administração do django através da adição de views na aplicação admin do Django.
Levando em conta que possuímos uma aplicação chamada questao, vamos adicionar uma views onde irá mostrar uma lista com as questões respondidas.
Segue o models.py:
from django.db import models
class Questao(models.Model):
pergunta = models.CharField(max_length=255)
resposta = models.TextField(blank=True)
def __unicode__(self):
return unicode(self.pergunta)
Com o modelo pronto podemos partir para parte da administração. Tudo é bem simples
e funciona da forma que costumamos criar associações comuns entre padrões de URL e
definições de views. Vamos ao admin.py:
from django import template
from django.contrib import admin
from django.conf.urls.defaults import *
from django.shortcuts import render_to_response
from models import Questao
class QuestaoAdmin(admin.ModelAdmin):
def questoes_respondidas(self, request):
objetos = self.model.objects.exclude(resposta='')
app_label = self.model._meta.app_label
return render_to_response('admin/%s/questaorespondida_list.html' % app_label,
{'objetos': objetos},
context_instance=template.RequestContext(request))
def get_urls(self):
urls = super(QuestaoAdmin, self).get_urls()
minhas_urls = patterns('',
(r'^questoes-respondidas/$', self.questoes_respondidas)
)
return minhas_urls + urls
admin.site.register(Questao, QuestaoAdmin)
Analisando o código podemos ver que temos duas definições de função no ModelAdmin QuestaoAdmin. A definição de get_urls retorna para o sistema de administração todas os padrões de urls disponíveis para a mesma, nela fizemos uma chamada dela mesma e associamos o seu resultado para a variável urls, com isso temos todas as as urls padrões da administração. Logo criamos o padrão de url para utilizarmos com a views que irá mostrar a lista de questões respondidas ( note que nela ao invés de adicionarmos o caminho para a função, utilizamos self pois a views esta contida na classe ). Feito o padrão de url retornamos a adição da nova url com as urls padrões, fazendo com que nossa url fique disponível para administração.
Tendo criado a url e apontado para a views estará tudo meio caminho andado. Agora vamos entender a views. A definição views é bastante familiar porem com apenas um parâmetro a mais que é o self. Logo na linha seguinte fazemos a queryset utilizando a instância criada pelo ModelAdmin em self.model, excluindo todos os linhas que não possuem resposta. Nas linhas seguintes utilizamos o render_to_response para renderizar o template juntamente com a queryset passada como contexto, podemos ver que para gerar o nome do template, foi feito de maneira dinâmica onde pegamos o nome da aplicação e utilizamos para especificar o diretório do template, isso é muito util quando você necessita criar uma funcionalidade genérica, onde a classe que a herdou possa ser utilizada por ela, mas nesse caso foi utilizado apenas por convenção minha. Lembrando que esta views é publica e não possui nenhuma restrição para acessos, sugiro que leia sobre permissões[1] antes de criar views para demonstração ( breve falarei sobre o assunto ).
Com tudo isto feito basta criar o template questaorespondida_list.html dentro do diretório de templates, que no nosso caso, ficara contido dentro de 'admin/questao/' ficando desta forma "templates/admin/questao/questaorespondida_list.html". Se no caso você optar por colocar seus templates juntamente com o diretório da aplicação, desta forma irá ser satisfatória, mas caso deseje colocar dentro de algum diretório de templates especificado no arquivo settings basta ignorar o primeiro diretório do exemplo ("admin/questao/questaorespondida_list.html"). Segue um pequeno html de exemplo:
<h1>Questões respondidas</h1>
<ul>
{% for obj in objetos %}
<li>
<h2>{{ obj.pergunta }}</h2>
{{ obj.resposta }}
</li>
{% endfor %}
</ul>
<p><a href="{% url admin:questao_questao_changelist %}">Voltar</a></p>
O exemplo de template é bem simples e pode ser melhor aproveitado de diversas formas e uma das mais comuns é estendendo os templates disponíveis da administração[2] mais um assunto para outro artigo.
Bem simples não? mas precisamos de algo para acessar esta pagina em nossa interface administrativa. Para isto faremos uma pequena alteração no template change_list.html para a aplicação questao. Faça uma copia do template change_list.html contido em 'django/contrib/admin/templates/admin/' para o mesmo diretório do template que criamos mais cedo e adicione as seguintes linhas dentro da lista '<ul class="object-tools">':
<li>
<a href="questoes-respondidas/" class="addlink">
Visualizar questões respondidas
</a>
</li>
Pronto, agora já foi solucionado o problema de acessibilidade. Acesse a administração e adicione algumas questões, tanto com resposta quanto sem e visualize a nova views da adminstração.
Faça o download do projeto exemplo: djadminviews.tar.bz2
[1] -
">">http://docs.djangoproject.com/en/1.1/topics/auth/#id1
[2] - http://docs.djangoproject.com/en/dev/ref/contrib/admin/#templates-which-may-be-overridden-per-app-or-model
Leia essa entrada em seu contexto
original »
A revista TiDigital responsavel por trazer as grandes novidades do mundo web, tras no mês de outubro a segunda parte do artigo Criando um microblog com Django, vale a pena conferir.
"Aplique efeitos e widgets interativos nos seus sites com a poderosa biblioteca jQuery UI. Saiba quando usar bancos de dados Relacionais, Orientados a Objetos e Orientados a Documentos. Yuri Marx fala sobre Java na web, cases Dindong e Vírgula, debate sobre Cloud Computing, e mais. Veja o sumário desta edição."
Leia essa entrada em seu contexto
original »
Neste mês, a revista TiDigital me convidou para escrever um artigo técnico sobre Django. E nesta primeira parte estarei falando sobre como criar um simples microblog com Django. Não deixe de conferir.
Acesse o site e confira mais detalhes sobre a edição: http://www.revistatidigital.com.br/
Leia essa entrada em seu contexto
original »
Uma das formas de optimização de paginas web é através da redução do seu tempo de carregamento. Um exemplo de deste tipo de optimização é removendo excessivos espaços em branco do código de sua pagina.
Django possui alguns meios para isto, e uma deles é através da tag de template {% spaceless %}[1], que remove todos os espaços em branco entre tags, de um trecho especificado. Porem, existe algumas restrições em relação à tag ```spaceless```, pois para quem a usa para esta finalidade, não poderá usa-lá caso esteja utilizando outro sistema de template.
Com isso, uma das formas de se fazer ```spaceless``` é através da criação de uma middleware[2], que utiliza a função ```strip_spaces_between_tags``` para remover espaços entre tags HTML. Com isso, sobrescreve-se o conteúdo do objeto ```response``` ( resposta ), que é passado para o método de middleware process_response[3] e logo em seguida é retornado o objeto response com os espaços removidos.
Segue um exemplo de middleware:
from django.utils.html import strip_spaces_between_tags as short
class SpacelessMiddleware(object):
def process_response(self, request, response):
if 'text/html' in response['Content-Type']:
response.content = short(response.content)
return response
Depois disto, no arquivo settings adicionar em MIDDLEWARE_CLASSES, o caminho à sua middleware.
Exemplo:
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'projeto.minhas_middlewares.SpacelessMiddleware',
)
Obs: Se estiver utilizando middleware de cache, lembre-se que a ordem das middlewares influencia. Então verifique se esta middleware estará antes da middleware de cache, para que seja feito cache com espaços removidos.
Com isto, todos os espaços entre tags serão removidos, o que lhes dará relativamente a redução do tamanho final do arquivo.
[1] = http://docs.djangoproject.com/en/dev/ref/templates/builtins/#spaceless
[2] = http://docs.djangoproject.com/en/dev/topics/http/middleware/#topics-http-middleware
[3] = http://docs.djangoproject.com/en/dev/topics/http/middleware/#process-response
Leia essa entrada em seu contexto
original »
Django é um framework web escrito em python [1] desenvolvido por uma equipe de jornalistas da Lawrence Journal Word [2] com o intuito inicial de ajudar na implementação de novas funcionalidades ou até mesmo na criação de novas aplicações. Django nasceu assim, num ambiente em que modificações da estrutura de web site eram quase constantes e com prazos estreitos para a entrega de uma solução. O sucesso, claro, veio por conseqüência! Django foi desenvolvido para isso, atender os curtos prazos.
A partir de 2005, Django foi amadurecendo e obtendo a capacidade de ser aplicado a vários tipos de sites, principalmente aqueles que possuíam um alto tráfego na rede, e isso fez com que os desenvolvedores decidissem torná-lo um projeto público Open-Source (código aberto) disponibilizado sob licença BSD ( Berkeley Software Distribution – licensa utilizada inicialmente em sistemas operacionais BSD ) e logo batizado com o nome Django. Segundo, F.A.Q. Geral do django [3] , o nome Django foi dado em homenagem ao guitarrista de Jazz Django Reinhardt e finalmente, em Junho de 2008, criou-se a Django Software Foundation [4] que a partir de agora será responsável pelas decisões que dizem respeito ao futuro do Django.
Hoje, com toda essa história por detrás de suas linhas de código, o Framework Django carrega consigo uma frase que marca sua forte característica “O framework web para perfeccionistas com prazos”, o termo perfeccionistas é utilizado pois o Django permite que o desenvolvedor produza aplicativos de maneira rápida e limpa, tornando os códigos menores e bem estruturados. É assim que o Django é conhecido, pois visa ao máximo a automatização no desenvolvimento e semeia a filosofia DRY[5] (Don't Repeat Yourself) que no bom português significa “não repita a si mesmo”, trata-se de um processo destinado a reduzir a duplicação, conduzindo o desenvolvedor a uma forma simples de criar seus aplicativos sem precisar reescrever o código, “re-aproveitando” o que já está pronto.
[1] http://www.python.org/
[2] http://www2.ljworld.com/
[3] http://docs.djangoproject.com/en/dev/faq/general/#what-does-django-mean-and-how-do-you-pronounce-it
[4] http://www.djangoproject.com/foundation/
[5] http://c2.com/cgi/wiki?DontRepeatYourself
Leia essa entrada em seu contexto
original »
