Tomemos por exemplo um projecto criado em Django com o nome "gestao".

1º Passo - Efectuar upload da framework e do projecto. A estrutura do directório no httpdocs deverá ser semelhante á imagem abaixo.
 

2º Passo - Editar o ficheiro .htaccess e enviar para a directoria base do dominio ou sub-dominio. Substituir <<dominio>> pelo endereço apropriado, ou colocar o path correcto que pode ser diferente do meu caso em especifico.

<Limit GET POST>
order deny,allow
deny from all
allow from all
</Limit>
<Limit PUT DELETE>
order deny,allow
deny from all
</Limit>
SetHandler python-program
AddHandler mod_python .py
Header set Pragma "no-cache"
Header set Cache-Control "no-cache"
Header set Expires "-1"
PythonPath "['/var/www/vhosts/<<dominio>>/httpdocs/django', '/var/www/vhosts/<<dominio>>/httpdocs/django/gestao'] + sys.path"
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE testes.settings
PythonDebug On

Para terminar, se tudo correr bem basta aceder ao endereço onde reside a aplicação e podemos verificar

Poderá não ser a melhor solução, mas foi a que para já serviu os meus propósitos, espero que ajude.

Estou a caminhar no sentido de migrar todos os meus websites pessoais para django, e realizar futuros projectos com esta Framework. E porquê? Basicamente porque fiquei conquistado com a facilidade com que desenvolvo aplicações, como faço o deployment das mesmas, como escalam com facilidade e sobretudo, a sua manutenção.

Um dos grandes problemas no Web developement, não passa tanto em desenvolver as aplicações inicialmente (Apesar de serem processos repetitivos), mas sim em manter as mesmas ao longo do tempo. Já tive grandes dores de cabeça com problemas de manutenção nos meus websites com PHP, mesmo recorrendo a Frameworks relativamente boas, como o Symfony ou Code Igniter, esta tarefa parece-me difícil quando comparado com Django.

Já houve uma altura que tentei seguir o hype, e percorri os caminhos de Framework Ruby on Rails, e apesar da facilidade com que construía Web apps, o problema residia no futuro, como irei manter estas aplicações, como vou resolver problemas mais complexos? RoR é muito flexível e permite até pessoas com poucos conhecimentos de programação, estabelecer modelos de negócio, em grande parte devido a máxima (Convention over Configuration). Mas o grande problema para mim, reside no simples facto de eu estar a vontade com a linguagem Ruby. Nunca tive o tempo, nem vontade de enveredar por aprender e conhecer a fundo a linguagem, o que me impede de desenvolver em RoR com segurança, e de expandir o código para alem do que a Framework me permite. Este para mim, foi o ponto chave que me levou a abandonar o desenvolvimento em RoR, isso e o facto do criador da linguagem ruby esclarecer alguns pontos engraçados em (How Ruby Sucks)

Com isto dito, é tempo de mudar para Django e deixar para trás 6 anos de PHP. E acho que não me vou arrepender, e porquê? Já tenho conhecimentos sólidos em python, e o que não tenho facilmente adiquiro, a documentação tanto para python como django são incríveis. A Framework já recebeu dois grandes apoios, o de Guido van Rossum, o criador do Python, e do Google, integrando uma parte da Framework no Google App Engine, e realizando diversos projectos apoiando o desenvolvimento desta Framework. 

Não me vou estender mais, a documentação do Djangoproject.com fala por si, está simplesmente bem documentado, possui um livro gratuito para iniciantes em djangobook.com. Aconselho vivavemente a explorar esta Framework, sobretudo pelas suas capacidades de CRUD, e o fantástico modo de administração que automaticamente é criado através do modelo de dados que establecemos, o interface encontra-se traduzido para português, e é super fácil de expandir e personalizar.

Quando ao alojamento para esta plataforma, ainda não existem muitos hosts em Portugal com suporte para tal, apenas me recordo de ter visto um ou dois no máximo, mas também pode ser desconhecimento da minha parte. No website do Django podemos encontrar hosts recomendados, alguns com preços muito convidativos.

De salientar que a versão 1.0 irá sair em Setembro, podendo utilizar algumas das novidades já na versão disponível do "trunk", que é bastante estável. Podem utilizar o SVN disponível para obter a ultima versão.

Links uteis:

http://www.djangoproject.com/
http://www.djangobook.com/
http://www.djangobrasil.org/
http://www.webmonkey.com/tutorial/Get_Started_With_Django/
http://www.sitepoint.com/article/build-to-do-list-30-minutes
http://metajack.wordpress.com/2008/06/12/5-reasons-to-love-django/
http://www.google.pt/search?q=django+filetype%3Apdf

É já amanha o SAPO Unplugged 2008. A realizar-se na reitoria da Universidade de aveiro, irá contar com uma cerimónia de inauguração de mais um laboratório powered by Sapo. Seguido de um evento que cobre o tema da usabilidade.

Eu lá estarei...

Programa - Website Oficial.

14:00 ABERTURA DA CONFERÊNCIA
FERNANDO RAMOS + CELSO MARTINHO

HENNING FISHER _ ADAPTIVE PATH
OSCAR MEALHA _ UNIVERSIDADE DE AVEIRO
PEDRO BRANCO _ UNIVERSIDADE DO MINHO

16:00 COFFEE-BREAK

IVO GOMES
BRUNO FIGUEIREDO
PEDRO CUSTÓDIO _ SAPO

18:30 ENCERRAMENTO
CELSO MARTINHO + PEDRO CUSTÓDIO

A interface responde com mais naturalidade e com princípios de usabilidade associados a aplicações desktop nas quais o utilizador encontra um ambiente mais familiar e natural.

A quantidade de informação transaccionada entre o Cliente e Servidor torna-se mais equilibrada, visto que o servidor Web não necessita de realizar todo o processamento e enviar para o cliente, permitindo que o mesmo servidor possa lidar com mais sessões de diferentes clientes.

Comunicação assíncrona. O interface do cliente pode interagir com o servidor de forma assíncrona, deste modo, uma acção na interface realizada pelo utilizador, como o clicar num botão, não precisa de esperar por uma resposta do servidor, e por sua vez que o utilizador espere pelo processamento. Talvez o mais comum é que estas aplicações, a partir de uma solicitação, antecipe uma futura necessidade de alguns dados, e estes são carregados no cliente antes de o utilizador os solicitar, de modo a acelerar uma resposta posterior. O site Google Maps utiliza esta técnica para, quando o utilizador move o mapa, os segmentos adjacentes são carregados no cliente antes mesmo que o utilizador voltar a mover o ecrã para essas áreas.

Estas são apenas algumas das vantagens que uma Web app beneficia com o seu transporte para o desktop.

Mas também existem desvantagens de uma RIA tradicional que funcione recorrendo apenas ao browser como forma de interagir com o utilizador.

O termo “sandbox” que utilizei anteriormente, pode ser benéfico em termos de segurança, mas prejudicar a extensibilidade que uma aplicação poderá ter, estando limitada no acesso ao sistema local do utilizador.

Processamento do lado do cliente, normalmente RIA’s fazem uso de javascript do lado do cliente para executar as mais diversas funções, se este estiver desactivado, torna-se um grande problema, como é uma linguagem interpretada, incorpora claras quebras de performance que não se verificariam em linguagens compiladas previamente, que é o normal nas aplicações desktop.

Perda de “estados”, ou seja, quando utilizamos uma RIA, esta tem de ser pensada na possiblidade de alguma forma guardar o estado actual da aplicação, quer esta aplicação seja feita em flash, javascript/html, ou outro sistema, é necessário garantir que o acesso pode ser quebrado a qualquer momento, e que quando resumido, possamos aceder ao “estado” anterior da aplicação, isto também é um problema para indexação em motores de pesquisa, pois não podem verificar claramente os diferentes estados dessa aplicação e a forma como a podem classificar. Mais uma vez, um exemplo claro é o Google Maps, que vai actualizando as coordenadas á medida que vamos navegando no mapa, criando um estado para um determinado momento, é possível fechar a aplicação e voltar mais tarde ao mesmo local e obter a mesma informação.

No próximo artigo irei falar dos benefícios que certos plugins/runtimes como Adobe AIR e Microsoft Silverlight, Google Gears, entre outros, trazem ás RIA’s tradicionais que operam apenas no browser. Já dei a conhecer alguns dos beneficios, mas irei explorar mais em concreto a utilização no desktop destas aplicações, e a nova guerra de Runtimes que anda a criar um grande buzz nos developers de Web apps, sobre qual a ferramenta mais indicada para levar a sua aplicação para o utilizador final.

 Pois bem, eu sou um dos muitos programadores frustrados, que querem algo mais de uma linguagem para desenvolver websites e web apps. Quero algo sólido, que me transmita confiança no trabalho que realizo, algo que envolva métodos e conceitos de programação bem estruturados e fundamentados, algo com que possa construir aplicações sem pensar nos problemas do dia de amanhã. Existem concerteza outras frameworks como as de PHP que já referi, ou o Django para python, ou Struts para Java, mas rails tem algo que me faz sentir bem, a sua simplicidade, a sua forma de abordar os problemas, enfim, ou então é mesmo por querer seguir o hype que a escolho como a minha framework do momento para desenvolver aplicações web. Não me vou estender mais.

Deixo alguns links interesantes para saberem mais sobre rails.

• www.rubyonrails.org
• http://api.rubyonrails.org/
• http://en.wikipedia.org/wiki/Model-view-controller
• http://en.wikipedia.org/wiki/Ruby_on_Rails
  
• http://rubyforge.org/
  
• http://railscasts.com/
  
• http://www.railslodge.com/