Olá pessoal, estou de volta, tentando manter o rigor de escrever pelo menos um post a cada semana. Como sempre, não estou com muito tempo, mas acho que estou melhorando na minha organização.
Nesse final de semana recebi uma demanda bem pequena de um projeto e decidi que iria desenvolvê-lo em Django, sabendo que ainda não tinha feito nada para o blog sobre isso, resolvi criar um pequeno post para os iniciantes nesse Framework.
O Django é um framework em Python. Ele possue uma arquitetura diferenciada, MTV (model, template e viewer). Tem poucas diferenças com o padrão MVC. Mas para continuar, em outro post explicarei melhor sobre esses detalhes. O Django se destaca por sua facilidade na criação rápida dos projetos.
Como uma boa prática em projeto com python, devemos instalar um ambiente separada para cada projeto, assim podemos utilizar versões diferentes de bibliotecas em projetos distintos sem ter interferencia entre eles.
Vamos lá, primeiro como gerenciador global dos pacotes, precisaremos instalar o EASY_INSTALL:
Em seguida por meio dele vamos instalar o PIP, um instalador de pacotes do python.
Agora só falta instalar o virtualenv que o é responsável pela criação dos ambientes para os projetos.
$ sudo pip install virtualenvwrapper
Seguindo, vamos criar a pasta do nosso projeto, criar o ambiente e ativar o ambiente. Depois disso qualquer pacote que instalarmos ficará isolado com relação ao resto do sistema,
$ mkdir projeto_django && cd projeto_django
$ virtualenv –no-site-packages env
$ source env/bin/activate
Estamos nesse instante na parte fácil que é instalar o Django e começar a brincar. Detalhe, deveremos estar com o ambiente ativado
Após a preparação do ambiente, enfim vamos criar nosso projeto Django com o comando django-admin.py usando o argumento startproject. Em seguida entre na pasta criada.
$ cd projeto
Observe que foi gerado uma estrutura parecida como da imagem ao lado.
O arquivo manage.py será nosso gestor do projeto, por meio dele, criaremos aplicações, faremos o sincronismo com o banco de dados, iniciaremos o servidor de teste e muitas outras opções.
Os arquivos que estão na subpasta com o mesmo nome do projeto terá a finalidade de configuração de diretivas e definição das urls.
Vamos testar para saber se o projeto está funcionando corretamente, assim execute o comando seguinte e acesso no browser: http://127.0.0.1:8000/
O Django como em vários outros frameworks, trabalha com modularização de aplicações, possibilitando a interações entre elas.
Com base no projeto que recebi, criaremos uma aplicação para controle de fotos.
Com a execução do comando, foi criado uma pasta chamada fotos e dentro dela mais três arquivos:
Partindo diretamente para a criação do modelo do banco de dados da nossa aplicação, vamos editar o arquivo models.py
from django.db import models
class Evento(models.Model):
nome = models.CharField(max_length=200)
data = models.DateTimeField()
local = models.CharField(max_length=200)
def __unicode__(self):
return self.nome
class Imagem(models.Model):
evento = models.ForeignKey(Evento)
legenda = models.CharField(max_length=200)
foto= models.ImageField(upload_to=’images’)
def __unicode__(self):
return self.legenda
Neste momento vamos definir o banco de dados e habilitar a aplicação no projeto, essa configurações devem ser feitas no settings.py. Observe os trechos de códigos a seguir:
Note que foi utilizado o sqlite3, mas poderia ser configurado com qualquer uma das quatro opções: postgresql_psycopg2′, ‘mysql’, ‘sqlite3′ ou ‘oracle’
DATABASES = {
‘default’: {
‘ENGINE’: ‘django.db.backends.sqlite3′,
‘NAME’: ‘./schema.sql’,
‘USER’: ”,
‘PASSWORD’: ”,
‘HOST’: ”,
‘PORT’: ”,
}
}
INSTALLED_APPS = (
‘django.contrib.auth’,
‘django.contrib.contenttypes’,
‘django.contrib.sessions’,
‘django.contrib.sites’,
‘django.contrib.messages’,
‘django.contrib.staticfiles’,
‘fotos’,
)
Agora a etapa se resume em criar o modelo físico do banco com um comando de sincronização. Além do model que escrevemos, esse comando criará mais algumas tabelas de manipulação de usuário o que já é padrão para o Django, assim não precisamos nos preocupar com essa parte.
Antes de criarmos o banco, devemos executar outro comando, pois, como estamos usando um campo do tipo imagem no model em nossa aplicação o Django precisará de um pacote para manipulação das imagens, assim será necessário instalá-lo.
$ python manage.py syncdb
Por fim, para temos realmente algo mais visível do projeto, vamos criar rapidamente o CRUD da aplicação, na qual representa a parte administrativa.
Primeiro vamos remover alguns comentários do arquivo urls.py, deixando-o como está abaixo.
OBS: adicionei uma url que não é padrão para termos acessarmos as imagens do upload.
from django.contrib import admin
admin.autodiscover()
urlpatterns = patterns(”,
url(r’^admin/’, include(admin.site.urls)),
url(r’^media/(?P<path>.*)$’, ‘django.views.static.serve’, {‘document_root’: settings.MEDIA_ROOT}),
)
admin.site.register(Evento)
admin.site.register(Imagem)
Será necessário outra alteração no arquivo settings.py para habilitar a aplicação de administração no projeto, adicione a linha: ’django.contrib.admin’, no array, INSTALLED_APPS.
Pronto, só precisamos sincronizar novamente o banco e iniciar o servidor de teste.
python manage.py syncdb
python manage.py runserver
Maravilha, estamos com a aplicação de certa forma pronta, acesse o endereço: http://127.0.0.1:8000/admin e coloque o usuário e senha criados no momento da geração do banco.
Foi rápido não foi ? Criamos um CRUD da nossa aplicação em pouquíssimo tempo.
Temos muitas outras possibildiades com Django, infelizmente em um único post isso não é possível.
Recomendo a visita nesses sites:
Fico por aqui, até a próxima.
Semana passa após muita tempo esperando, consegui desbloquear meu iPhone 4. Comprei ele no Estados Unidos, sabendo que estava bloqueado pela operadora AT&T, esperei um tempo até conseguir usar, pois tive que adiquir o chip GEVEY.
Depois de uma desatenta atualização para o IOS 5.0, meu baseband (firmware do modem) foi modificado para versão 04.11.08 e desde lá estou com o aparelho parado.
Com uma insistente pesquisa sobre o modo de desbloquei oferecido pela AT&T, encontrei diversas posts sobre o assunto mas nenhum muito concreto, até que em um fórum encontrei o caminho das pedras.
Vou descrever duas formas diferentes para solicitar o desbloqueio, sugiro que tente as duas para garantir.
Para adiantar um pouco a história e ajudar quem quer desbloquear, vou contar como é o procedimento normal para solicitar o desbloqueio:
Eu consegui de outra forma, um pouco mais rápida:
Caso não tenha o comprovante de compra, sugiro que utilize o GEVEY ultra que pode ser comprado nesse site http://www.applenberry.com
Galera fica ai a dica e brevemente estou com novos posts.
Fontes:
http://forums.macrumors.com/archive/index.php/%2520download%2520piarco%2520/t-1355053-p-2.html
http://www.iphonefaq.org/archives/971891
Estou de volta com um post direcionado à área técnica. O objetivo deste post é apresentar as principais diferenças da nova versão do Framework Symfony, com relação a versão anterior. O post se fez necessário, houve algumas mudanças bem relevantes.
Pra quem não conhece o Symfony1, ele tem uma abordagem muito parecida com o Zend Framework, com sua essência na arquitetura MVC. Um detalhe interessante é a abertura na camada de Model, permitindo o vínculo com outros Frameworks conhecidos por ORM`s, como: Propel e Droctrine.
Abaixo tenho um demonstrativo da relação dos principais itens técnicos sobre as duas versões:
| symfony 1,4 | Symfony 2,0 | |
|---|---|---|
| Estabilidade | Estável | Estável |
| Data de lançamento | 11/2009 | 07/2011 |
| Últimas | 1.4.13 | 2.0.0 |
| Apoio | 3 anos | n / a |
| PHP versão | > = 5.2.4 | > = 5.3.2 |
| Versões ORM | Propel: 1.4 Doutrina: 1.2 |
Doutrina: 2.1 |
| Fim da manutenção | 11/2012 | n / a |
| Documentação | Documentação | Documentação |
| Instalação | Instruções detalhadas | Instruções detalhadas |
| Repositório principal | http://svn.symfony-project.com/branches/1.4 | http://github.com/symfony/symfony.git |
O salto da versão do Symfony não é por acaso, tanto sua estrutura quanto seu conceito foram afetados, e com certeza a forma de criação dos projetos. Então vamos lá.
Ressalto que todas habilidades aplicadas para dominar um projeto no Symfony1 continuam a ser muito relevante no desenvolvimento em Symfony2.
Com uma pequena analise em uma projeto com Symfony2, percebemos que houve várias alterações em sua estrutura de diretórios. Suas mudança aplicam-se:
No Symfony1, o projeto contém uma ou mais aplicações, e todos dentro do diretório/app. Por padrão no Symfony2, encontraremos apenas uma aplicação no projeto. Nesse diretório teremos configurações específicas para cache, logs e diretórios de templates, bem como uma classe Kernel (AppKernel), que será responsável por definir quais bundles serão utilizados na aplicação.
Esse diretório é bem parecido com o diretório /plugins do Symfony1. Seu propósito foi de centralizar todos o códigos de uma determinada aplicação em um só lugar. No Symfony1, tínhamos vários apps, onde poderíamos compartilhar vários plugins e outros códigos PHP. Porém ficavam em diretórios separados. No Symfony2, a vida é muito mais simples porque todo o código deve estar em um pacote.
O /vendor é equivalente ao diretório /lib/vendor do Symfony1, abrangendo todas as bibliotecas vendor e bundles. Por padrão, encontraremos nesse diretório os arquivos da biblioteca Symfony2, juntamente com várias outras bibliotecas dependentes, como Doctrine2, Twig e SwiftMailer.
Quase não houve alterações nesse diretório. A diferença mais notável é a ausência dos diretórios /css, /js, /images. Isso é intencional. Como todos os códigos PHP devem ficar juntos, os ativos também devem estar dentro do mesmo pacote.
Com a ajuda de um comando de console, os arquivos do diretório Resources/public/ de cada pacote é copiado ou simbolicamente ligado ao diretório /web/bundles/.
Isto permite-lhe manter os ativos organizados dentro do seu pacote, mas ainda torná-los disponíveis ao público.
Autoloading mudou no Symfony2, agora é mais universal, mais rápido, e independente da necessidade de limpar o cache.
No Symfony1, autoloading foi feito através de pesquisas em todo o projeto para buscar os arquivos de classe PHP e incluía em cache estas informações em uma matriz gigante.
Quem lida com esse processo no Symfony2 é uma nova classe chamada : UniversalClassLoader. A idéia por trás do autoloader é simples: o nome da classe (incluindo o namespace) deve coincidir com o caminho para o arquivo que contém essa classe. Veja o exemplo:
namespace Sensio\Bundle\FrameworkExtraBundle;
use Symfony\Component\HttpKernel\Bundle\Bundle;
// ...
class SensioFrameworkExtraBundle extends Bundle
{
// ...
Com o Symfony1, o console está no diretório raiz do seu projeto e é chamado symfony:
php symfony
No Symfony2, o console é agora no sub-diretório app:
php app/console
Em um projeto Symfony1, é comum ter várias aplicações: uma para o frontend e outra para o backend, por exemplo. No Symfony2, só precisamos criar uma aplicação (uma aplicação de blog, um aplicativo de intranet, …). Na maioria das vezes, se quisermos criar uma segunda aplicação, podemos em vez disso criar outro projeto e compartilhar alguns pacotes entre eles.
Caso precisarmos separar a interface e os recursos de backend de alguns pacotes, criaremos sub-diretórios para os controladores, sub-diretórios para modelos, configurações de semântica, configurações de roteamento, e assim por diante.
Claro, não há nada de errado em ter várias aplicações em um projeto. A segunda aplicação significaria um novo diretório, por exemplo, /my_app, com a mesma configuração básica do diretório /app.
Um plugin no Symfony1 pode conter arquivos de configuração, módulos, bibliotecas PHP, ativos e qualquer outra coisa relacionada ao seu projeto. Em Symfony2, a idéia é que um plugin seja substituído por ”pacote” (bundle). Um conjunto ainda mais poderoso do que um plugin.
Um plugin deve ser ativada dentro da classe ProjectConfiguration, isso quando utilizamos o Symfony1:
// config/ProjectConfiguration.class.php
public function setup()
{
$this->enableAllPluginsExcept(array(/* some plugins here */));
}
No Symfony2, os bundles são ativadas dentro do AppKernel:
// app/AppKernel.php
public function registerBundles()
{
$bundles = array(
new Symfony\Bundle\FrameworkBundle\FrameworkBundle(),
new Symfony\Bundle\TwigBundle\TwigBundle(),
// ...
new Acme\DemoBundle\AcmeDemoBundle(),
);
return $bundles;
}
No Symfony1, os arquivos de configuração routing.yml e app.yml foram carregados automaticamente dentro de qualquer plugin. O processo muda um pouco no Symfony2, roteamento e configuração da aplicação fica dentro de um pacote que devem ser incluídos manualmente. Por exemplo, para incluir um recurso de roteamento de um pacote chamado AcmeDemoBundle, faremos o seguinte:
# app/config/routing.yml
_hello:
resource: "@AcmeDemoBundle/Resources/config/routing.yml"
Isso irá carregar as rotas encontradas no Resources/config/routing.yml do AcmeDemoBundle. O especial @AcmeDemoBundle é uma sintaxe de atalho que, internamente, resolve para o caminho completo para esse pacote.
Podemos usar esta mesma estratégia para trazer na configuração de um pacote:
# app/config/config.yml
imports:
- { resource: "@AcmeDemoBundle/Resources/config/config.yml" }
Essas são as principais modificações, porém não acabamos por ai. Recomendo, caso queria inciar a criação de projetos utilizando Symfony2, não deixe de ler a documentação, isso é essencial.
Fico por aqui.
Fontes:
http://symfony.com/doc/current/cookbook/symfony1.html