A vantagem do GeDA é a facilidade na configuração. Basta adicionar o JAR no seu projeto e montar os DTO’s a partir das entidades. Depois disso, basta adicionar as anotações no DTO e depois criar uma classe para realizar o Assembly entre a Entidade e o DTO. Calma, vou explicar mais detalhadamente logo abaixo.

Configuração

O primeiro passo é fazer o download da biblioteca no site oficial ou diretamente do source forge. Por fim, basta adicionar o jar ao build path do projeto.

Criando um DTO

Apenas para exemplificar, vou criar uma Entidade Usuario:

@Entity
@Table(name="usuario")
public class Usuario {
 
 @Id
 private Long id;
 private String nome;
 private String login;
 private String senha;
 // Get's e Set's
}

E agora vou mapear esta entidade em um DTO usando as anotações do GeDA:

@Dto
public class UsuarioTO {
 
    @DtoField("id")
    private Long idUsuario;
 
    @DtoField
    private String nome;
 
    @DtoField
    private String login;
 
    @DtoField
    private String senha;
    // Get's e Set's
}

Importante destacar aqui, o uso da anotação @DtoField. No Id, eu precisei definir o nome original do campo, pois modifiquei-o no meu DTO. Como os outros campos possuem o mesmo nome, não há necessidade de informar o nome do campo na entidade.

Copiando as informações

Agora vamos criar a classe que realizará o assembly:

public class UsuarioService {
    public UsuarioDTO getUsuario(final Long idUsuario) {
        final Usuario usuario = getFromDb(idUsuario);
        final UsuarioDTO dto = novoTO();
        final DTOAssembler assembler = DTOAssembler.newAssembler(UsuarioDTO.class, Usuario.class);
        assembler.assembleDto(dto, usuario, null);
        return dto;
    }
 
    public UsuarioDTO novoTO() {
        return new UsuarioDTO();
    }
 
    public Usuario getFromDb(final Long idUsuario) {
        // aqui teria um código para buscar um usuário do banco
    }
}

É um exemplo simples e rápido, mas o suficiente para mostrar como é simples realizar o assembly entre uma entidade e um DTO. É possível fazer as duas conversões, no método do Service, bastaria mudar a chamada do método assembleDto para assembleEntity.

Concluindo

Existem outras coisas possíveis, como copiar objetos, listas, etc. Para isso, sugiro uma visita ao faq no site oficial, onde é possível visualizar alguns exemplos de conversões. Apesar da documentação ser bastante fraca, é possível se basear nos exemplos para suprir praticamente todas as necessidades.

Uma última dica, para quem deseja utilizar o GeDA em aplicações reais, sugiro a criação de um Assembler genérico, o que facilitará bastante o processo de copia dos valores.

Desde que fiz o curso de Técnico em Sistemas de Informação no antigo CEFET-RS, tinha vontade de ir ao FISL e nunca conseguia. Geralmente o maior problema era o trabalho, pois o fórum começa na quarta-feira e vai até sábado. Este ano, meu amigo Davi Schneid organizou uma excursão para os “trabalhadores”, com o intuito de ir apenas no sábado. Como o valor das inscrições para “última hora” são meio abusivos (R$ 200,00) quando comparados aos preços iniciais (R$ 40,00), decidimos ir apenas para passear.

De uma forma geral, foi meio decepcionante para mim, pois esperava algo ainda maior do que já é. Como não iríamos assistir nenhuma palestra, chegamos lá e fomos olhando os stands montados. Até que tinha bastante coisa, mas não tem muito o que fazer após uma ou duas voltas pelos stands. No máximo ficar na volta do stand do IG, hehehehe.

No fim das contas, valeu pela companhia da gurizada da Gestum. Gosto de continuar tendo contato com eles, independente de não trabalhar mais lá.

Gostaria de parabenizar ao Fábio pela iniciativa e pela agilidade em enviar o prêmio, pois 3 dias depois o livro estava na minha casa.

Pra falar a verdade, não sabia exatamente do que se tratava o livro, então nada melhor que uma resenha para mostrar isso. Uma única “googlada” e encontrei um post no blog do Miguel Cavalcanti com a tal resenha. Vale a pena dar uma lida e, caso goste, comprar o livro.

Vídeo do Sorteio:

Sorteio dos livros Rework, da 37Signals from Fabio Vedovelli on Vimeo.

Detalhe que eu ganhei 2 vezes! hehehehe

Acredito que o maior benefício é evitar a reescrita de código ou a famosa duplicação de código, que geralmente nos remete à código do backend, mas dessa vez na view.

Por exemplo, tenho que desenvolver um sistema que possui 5 cadastros do tipo CRUD para alimentar a base com informações. Pois bem, quais os componentes necessários para um CRUD? Um dataTable, para apresentar a lista dos registros do banco e um formulário para cadastrar e editar os dados. Partindo desse princípio, o que normalmente nós faríamos é criar um primeiro CRUD completo para servir de “base” para os outros e fazer o famoso copy/paste, trocar os valores dos formulários e ta pronto. Uma maravilha! Ou não…

Duas semanas depois, nós estámos já desenvolvendo alguns recursos necessários para a aplicação e uma mudança de layout foi realizada: agora as mensagens de validação de campos devem ser apresentadas abaixo de cada campo. Ferrou! Retrabalho editando todos os formulários que nós tínhamos.

É aqui que entra o nosso amigo Facelets. Com ele nós podemos criar componentes para diversos propósitos, como, por exemplo, formulários. Sei que já existe o h:inputText e a minha ideia não é escrever um novo inputText, mas sim, incrementá-lo. A maioria dos formulários possui a mesma estrutura: “Label:” [Campo]. Então, normalmente nós faríamos o seguinte:

<h:outputLabel for="nome" id="nomeLabel" value="Nome: " />
<h:inputText id="nome" value="#{mBean.user.name}" required="true" />
<h:message for="nome" />

Isso iria se repetir para cada campo do tipo texto do todos os formulários do sistema. No exemplo, eu já adicionei o h:message para o input, mas na nossa história isso não existia no CRUD “base” e tivemos que alterar tudo depois. Agora vamos criar um componente que apresente esse nosso formato usando apenas uma tag:

<asn:formInput id="nome" label="Nome: " value="#{userMBean.nome}" required="true" />

O resultado deverá ser o mesmo apresentado antes, porém temos o componente centralizado, nos possibilitando de alterar apenas um arquivo para que todo o sistema se encaixe no requisito.

Mas como a gente faz isso tio? Bueno, mãos à obra:

Criando o componente

A primeira coisa a fazer, é escrever o componente. Monte tudo que você precisar. O meu ficou assim:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
                      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:ui="http://java.sun.com/jsf/facelets"
      xmlns:h="http://java.sun.com/jsf/html">

 <ui:component>
     <h:outputLabel for="#{id}" id="#{id}Label" value="#{label}" />
     <h:inputText id="#{id}" value="#{value}" required="#{required}" />
     <h:message for="#{id}" />
 </ui:component>
</html>

Os valores id, value e required, serão os parâmetros do nosso componente.

Criando a TagLib

Feito isso, precisamos criar a nossa taglib:

<?xml version="1.0"?>
<!DOCTYPE facelet-taglib PUBLIC "-//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN"
    "https://facelets.dev.java.net/source/browse/*checkout*/facelets/src/etc/facelet-taglib_1_0.dtd">

<facelet-taglib>
    <namespace>http://asneto.eti.br/java/jsf</namespace>
    <tag>
         <tag-name>formInput</tag-name>
         <source>formInput.xhtml</source>
    </tag>
</facelet-taglib>

Observe que o “source” é o caminho para o arquivo que contém o nosso componente. Como eu deixei na mesma pasta da taglib, apenas coloquei o nome do arquivo. Agora vamos registrar a taglib na nossa aplicação. Abra o seu web.xml e coloque:

<context-param>
    <param-name>facelets.LIBRARIES</param-name>
    <param-value>/WEB-INF/components/asneto.taglib.xml</param-value>
</context-param>

Observe o caminho para o xml da taglib. Foi nesse caminho que salvei os arquivos. Você pode colocar em qualquer lugar, mas preferencialmente coloque fora das pastas públicas do projeto.

Testando

Bacana, vamos testar agora. Crie um formulário de exemplo utilizando o componente recém criado:

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:asn="http://asneto.eti.br/java/jsf">
<head>
    <title>Teste</title>
</head>
<body>
    Teste de componentes
    <h:form>
        <asn:formInput id="nome" label="Nome: " value="#{userMBean.nome}" required="true" />
    </h:form>
</body>
</html>

E o resultado no browser:

Legal, mas esse exemplo é bobinho né? Claro, é apenas pra exemplificar. Tive um caso real, onde os CRUD‘s tinham modais de confirmação, tipo o “alert()” do JavaScript, mas mais moderno. Para não ficar repetindo código em todos os CRUD‘s, criamos um componente que tinha um rich:modalPanel com botões “Sim” e “Não” e recebia uma mensagem como parâmetro (além de muitos outros como a action do botão sim e tal). Isso facilitou bastante, pois apenas mexendo no componente, todo o sistema estava alterado.

Incrementando o exemplo

Criando um TLD para o componente.

Os “TLD” (taglib descriptor) são a documentação do nosso componente. É desse arquivo que as IDE’s lêem para exibir as informações no autocomplete:

<!DOCTYPE taglib PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN"
    "http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd">

<taglib xmlns="http://java.sun.com/JSP/TagLibraryDescriptor">
    <tlib-version>1.0</tlib-version>
    <jsp-version>2.0</jsp-version>
    <short-name>Components</short-name>
    <uri>http://asneto.eti.br/java/jsf</uri>
    <display-name>ASNeto TagLibrary</display-name>
    <tag>
         <name>formInput</name>
         <tag-class />
         <body-content>empty</body-content>
         <description>
             Componente para campos de formulários. Exibe uma label, o campo do tipo input e a mensagem de validação.
         </description>
         <attribute>
             <name>id</name>
             <required>true</required>
             <rtexprvalue>false</rtexprvalue>
             <type>java.lang.String</type>
             <description>
                 Id do componente.
             </description>
         </attribute>
         <attribute>
             <name>label</name>
             <required>false</required>
             <rtexprvalue>false</rtexprvalue>
             <type>java.lang.String</type>
             <description>
                 Label do campo.
             </description>
         </attribute>
         <attribute>
             <name>value</name>
             <required>true</required>
             <rtexprvalue>false</rtexprvalue>
             <type>java.lang.String</type>
             <description>
                 Valor ao qual o input está associado.
             </description>
         </attribute>
         <attribute>
             <name>required</name>
             <required>false</required>
             <rtexprvalue>false</rtexprvalue>
             <type>java.lang.Boolean</type>
             <description>
                 Informa se o campo é obrigatório ou não.
             </description>
         </attribute>
    </tag>
</taglib>

Criando parâmetros não obrigatórios

Nossos componentes devem poder receber parâmetros não obrigatórios. Digamos que no nosso sistema, todas as labels são com cor vermelha e os inputs tem borda verde. Vamos setar um styleClass direto no componente? Pode ser, vai funcionar, mas estaremos engessando nosso componente. O ideal é possibilitarmos que a classe CSS para a label e para o input sejam passados por parâmetro.

Com as devidas alterações, nosso componente agora ficou assim:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
	    xmlns:ui="http://java.sun.com/jsf/facelets"
            xmlns:h="http://java.sun.com/jsf/html"
            xmlns:c="http://java.sun.com/jsp/jstl/core">

    <ui:component>
        <c:if test="#{styleClass}">
            <c:set value="false" var="styleClass" />
        </c:if>

        <c:if test="#{labelStyleClass}">
            <c:set value="false" var="labelStyleClass" />
        </c:if>

        <h:outputLabel for="#{id}" id="#{id}Label" value="#{label}" styleClass="#{labelStyleClass}" />
        <h:inputText id="#{id}" value="#{value}" required="#{required}" styleClass="#{styleClass}" />
        <h:message for="#{id}" />
    </ui:component>
</html>

Observem que eu agora é possível passar a classe CSS para a label e/ou para o nosso input. Eu usei JSTL pois ela é executada antes do parse do Facelets. Portanto, caso o parâmetro não tenha sido setado, o JSTL vai criar uma variável local (através do c:set) possibilitando o uso da mesma.

Usando máscara com jQuery

Um caso que sempre vejo na lista JavaSF, é referente ao uso de máscaras com jQuery (meio.mask, input.mask). O problema é que o reRender realizado acaba não chamando o JavaScript para aplicar a máscara denovo, fazendo com que os inputs percam a máscara setada. Uma boa maneira de resolver este problema, é usar um componente que, além de ter a máscara, tenha a chamada JavaScript para a aplicação da mesma. Dessa forma, ao dar um reRender no componente, a máscara é aplicada junto. Neste exemplo vou usar o plugin meio.mask que pode ser baixado do site oficial.

Alterando nosso componente para receber máscara:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
	    xmlns:ui="http://java.sun.com/jsf/facelets"
            xmlns:h="http://java.sun.com/jsf/html"
            xmlns:rich="http://richfaces.org/rich"
            xmlns:c="http://java.sun.com/jsp/jstl/core">

    <ui:component>

        <c:if test="#{!styleClass}">
            <c:set value="false" var="styleClass" />
        </c:if>

        <c:if test="#{!labelStyleClass}">
            <c:set value="false" var="labelStyleClass" />
        </c:if>

        <c:if test="#{!mask}">
            <c:set value="" var="mask" />
            <c:set value="false" var="useMask" />
        </c:if>

        <c:if test="#{mask}">
            <c:set value="true" var="useMask" />
        </c:if>

        <h:outputLabel for="#{id}" id="#{id}Label" value="#{label}" styleClass="#{labelStyleClass}" />
        <h:inputText id="#{id}" value="#{value}" required="#{required}" styleClass="#{styleClass}" />
        <h:message for="#{id}" />

        <rich:jQuery selector="##{id}" query="setMask('#{mask}')" timing="immediate" />

    </ui:component>
</html>

Agora temos o novo parâmetro “mask” que não é obrigatório. Para usarmos esse input, temos que carregar o script do meio.mask. Eu fiz isso na tela onde eu uso o input, assim caso não seja usado nenhuma máscara, não há necessidade de carregar o script.

Usando nosso componente alterado:

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:asn="http://asneto.eti.br/java/jsf"
      xmlns:a4j="http://richfaces.org/a4j">
    <head>
        <script type="text/javascript" src="js/jquery.meio.mask.js" />
        <title>Teste</title>
    </head>
    <body>
        Teste de componentes
        <h:form id="form" prependId="false">
            <h:panelGroup id="bloco">
                <asn:formInput id="nome" label="Nome: " value="#{userMBean.nome}" required="true" mask="99:99" />

                <br />

                <a4j:commandLink value="reRenderizar Bloco">
                    <a4j:support event="onclick" reRender="bloco" />
                </a4j:commandLink>
            </h:panelGroup>
        </h:form>
    </body>
</html>

Adicionei um link para reRenderizar o bloco, mostrando como a máscar permanece, mesmo após o recarregamento.

Finalizando

O Facelets facilita a nossa vida, basta saber utilizá-lo. Lembrando, este recurso serve para evitar a reescrita de código na View, caso você precise criar um componente novo, o melhor é utilizar componentes nativos para JSF, usando código Java. Fiz esse post meio rápido, então qualquer erro encontrado, por favor me notifiquem para que eu corriga o post.

Destaque para a criatividade nos nomes dos personagens. Divirta-se!

O Netbeans chega na sua versão 6.9. Confira o vídeo abaixo para conhecer os novos recursos:

O Netbeans possui versões para Windows, Linux, MAC e Solaris. Acesse o site da IDE e faça o download.

Já o Eclipse teve a sua versão 3.6 apresentada sob o codinome Helios. As 10 principais novidades do Helios são:

1. Resource Improvements
2. Feature based configurations
3. Improvements to API Tools
4. Java IDE Improvements
5. Target Platform Improvements
6. p2 API and the b3 Aggregator
7. MarketPlace Client
8. EMF, Riena and RAP integration
9. Git Support at Eclipse
10. Xtext, Version 1.0.

Com diversas opções de download o Eclipse suporta os sistemas operacionais Windows, Linux e MAC. Acesse a página de downloads do Helios para baixar a versão que melhor servir para o seu desenvolvimento.

O que é CodeIgniter?

O CodeIgniter é um framework de desenvolvimento de aplicações em PHP. Seu objetivo é possibilitar que o desenvolvedor crie projetos mais rapidamente do que se estivesse codificando do zero. Isso é possível por meio de um abrangente conjunto de bibliotecas voltadas às tarefas mais comuns, de uma interface e uma estrutura lógica simples para acesso àquelas bibliotecas. O CI, permite ainda que se mantenha o foco no projeto, minimizando a quantidade de código que seria necessário desenvolver, sem o uso de um framework.

Meu objetivo não é esplanar tudo sobre o CodeIgniter, portanto para saber mais vou deixar alguns links:

• Site oficial do CodeIgniter
• Manual do CodeIgniter (Inglês)
• Manual do CodeIgniter (Português)

O que é Doctrine?

O Doctrine é um framework de Mapeamento Objeto-Relacional (ou ORM) para PHP. O ORM é uma técnica de desenvolvimento utilizada para reduzir a impedância da programação orientada aos objetos utilizando bancos de dados relacionais. As tabelas do banco de dados são representadas através de classes e os registros de cada tabela são representados como instâncias das classes correspondentes. É um recurso amplamento utilizando em outras linguagens como Java com o Hibernate ou .NET com NHibernate.

Porque fazer essa integração?

Boa pergunta. Porque diabos eu tenho que fazer isso? Eu comecei a programar com PHP e depois comecei a mexer com Java. Após todo o conhecimento adquirido com o Java, depois de saber as facilidades que o ORM proporciona, fica complicado de voltar a trabalhar no modo “manual”. Claro que o ORM não é a melhor coisa que existe, mas ele ajuda bastante, principalmente na hora de criar coisas básicas como CRUD’s e listagens simples. Com essa integração vai ficar fácil criar, editar, atualizar e excluir registros de uma tabela do banco de dados, tratando tudo como Objetos. Existem outros benefícios que podem ser lidos nessa introdução ao Doctrine.

Para visualizar melhor o que vai mudar, este é o modelo MVC com o fluxo do CodeIgniter:

E agora, onde vai entrar o Doctrine:

Mas o que significa cada uma dessas novas camadas?

Doctrine ORM: é uma API de mapeamento Objeto-Relacional. Faz a ponte entre o model e as entidades.

Doctrine DBAL: API de abstração de banco de dados.

PDO: API cross-database. O CI já possui uma API semelhante, que permite o uso de diversos bancos, mas o doctrine vai utilizar uma API própria. No fim das contas, nada se perde, pois essa API tem a mesma função da API já existente no CI.

Instalando o CodeIgniter

Chega de blá blá blá. Vamos para a parte boa. A primeira coisa a se fazer é uma instalação clean do CI. Para isto basta baixar a última versão no site. No momento deste post, a última versão do CI é a 1.7.2.

Download CodeIgniter

Após realizar o download, extraia o conteúdo da pasta para o local de sua preferência. A estrutura deverá ser algo assim:

A pasta “user_guide” é o guia do usuário em inglês. Você não vai precisar dela. Agora mova a pasta raiz do CI para o seu servidor web e ao acessá-lo pelo browser você deve ver uma tela de boas vindas como essa:

Como funciona o CodeIgniter

Os controllers são chamados a cada requisição. Eles estão localizados na pasta:

/system/application/controllers/

A estrutura das URL’s estão diretamente ligadas aos controlers, dessa forma:

http://localhost/codeigniter/index.php/NOME_CONTROLLER/NOME_FUNCTION

Faça um teste, crie um novo controller ou modifique o que já existe (welcome.php) para entender melhor o funcionamento. Recomento que seja feita uma leitura no manual (links no topo). Lá existe uma seção explicando o funcionamento de cada camada do CodeIgniter.

Instalando o Doctrine

Baixe a última versão estável do doctrine pelo site oficial:

Download Doctrine

Crie a pasta:

/system/plugins/doctrine

Extraia o conteúdo da pasta “lib” do pacote do Doctrine e copie para a pasta recém criada. A estrutura deverá ser esta:

Agora precisamos criar o arquivo do plugin que vai interligar o Doctrine ao CI. Crie o arquivo:

/system/plugins/doctrine_pi.php

E copie o conteúdo abaixo:

// Carrega a biblioteca do Doctrine
require_once BASEPATH.'/plugins/doctrine/lib/Doctrine.php';
 
// Carrega as configurações de banco de dados do CodeIgniter
require_once APPPATH.'/config/database.php';
 
// Permite ao Doctrine carregar automaticamente as classes Model
spl_autoload_register(array('Doctrine', 'autoload'));
 
// Precisamos carregar nossas conexões no Doctrine_Manager
// Este loop permite a utilização de múltiplas conexões
foreach ($db as $connection_name => $db_values) {
 
// Primeiro convertemos para o formato DSN
$dsn = $db[$connection_name]['dbdriver'] .
'://' . $db[$connection_name]['username'] .
':' . $db[$connection_name]['password'].
'@' . $db[$connection_name]['hostname'] .
'/' . $db[$connection_name]['database'];
 
Doctrine_Manager::connection($dsn,$connection_name);
}
 
// A class Model do CodeIgniter precisa ser carregada
require_once BASEPATH.'/libraries/Model.php';
 
// Localização dos models para o Doctrine
Doctrine::loadModels(APPPATH.'/models');
 
// Configurações Opcionais
 
// Permite o uso de "mutators"
Doctrine_Manager::getInstance()->setAttribute(
	Doctrine::ATTR_AUTO_ACCESSOR_OVERRIDE, true);
 
// Seta todas as colunas para notnull e unsigned (para ints) por padrão
Doctrine_Manager::getInstance()->setAttribute(
	Doctrine::ATTR_DEFAULT_COLUMN_OPTIONS,
	array('notnull' => true, 'unsigned' => true));
 
// Seta para todas as tabelas uma chave primária chamada "id" de 4 bytes
Doctrine_Manager::getInstance()->setAttribute(
	Doctrine::ATTR_DEFAULT_IDENTIFIER_OPTIONS,
	array('name' => 'id', 'type' => 'integer', 'length' => 4));

Configurando o banco de dados

Crie uma tabela no banco de dados de sua preferência. Aqui eu uso MySQL e vou criar um banco de dados chamado “ci_doctrine”, sem nenhuma coluna. Depois configure a conexão com o banco de dados no arquivo:

/system/application/config/database.php

Encontre as linhas abaixo e troque pelas configurações do seu servidor:

$db['default']['hostname'] = "localhost";
$db['default']['username'] = "root";
$db['default']['password'] = "";
$db['default']['database'] = "ci_doctrine";
$db['default']['dbdriver'] = "mysql";

Últimas configurações

Agora precisamos fazer as configurações finais. Primeiro abra o arquivo

/system/application/config/config.php

E altere a seguinte linha:

// Aqui deve ser definido o caminho da sua aplicação. No meu caso é:
$config['base_url'] = "http://localhost/codeigniter/";

Agora abra o arquivo:

/system/application/config/autoload.php

E altere a seguinte linha:

$autoload['plugin'] = array('doctrine');

Pronto!

Agora vamos testar nossa integração.

Testando a integração

Lembram da base “ci_doctrine” que criamos lá encima? Agora vamos adicionar uma tabela à ela. Execute o SQL abaixo:

CREATE TABLE USER (
	id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
	username VARCHAR(255) NOT NULL,
	password VARCHAR(255) NOT NULL,
	first_name VARCHAR(255) NOT NULL,
	last_name VARCHAR(255) NOT NULL,
	UNIQUE (username)
)

Agora crie o Model da tabela “user” e salve na pasta:

/system/application/models/

class User extends Doctrine_Record {
 
	public function setTableDefinition() {
		$this->hasColumn('username', 'string', 255);
		$this->hasColumn('password', 'string', 255);
		$this->hasColumn('first_name', 'string', 255);
		$this->hasColumn('last_name', 'string', 255);
	}
 
}

Explicando:

• Os models devem extender de “Doctrine_Record” e não mais de “Model”.
• Na função setTableDefinition, devemos definir qual a estrutura da tabela à qual este model está relacionado
• Por padrão, o Doctrine vai tentar relacionar esta classe à uma tabela com o mesmo nome, neste caso “user”. Isto pode ser modificado.
• No nosso arquivo doctrine_pi.php que criamos agora a pouco, definimos que todas as tabelas possuem uma primary key chamada id, portanto não precisamos declará-la neste momento.

Adicionando usuários

Para testar nossa integração, vamos criar um controller chamado usermanager.php. Para isto copie o código a seguir no arquivo:

/system/application/controllers/usermanager.php

class Usermanager extends Controller {
 
	function user_test() {
		$u = new User;
		$u->username = 'fulano';
		$u->password = '12345';
		$u->first_name = 'Fulano';
		$u->last_name = 'de Tal';
		$u->save();
 
		$u2 = new User;
		$u2->username = 'Usuário';
		$u2->password = 'Senha';
		$u2->first_name = 'Nome';
		$u2->last_name = 'Sobrenome';
		$u2->save();
	}
 
}

Acima criamos 2 usuários, setamos seus valores, e apenas chamando o método “save” temos os dados persistidos na tabela “user”.

• Podemos acessar as colunas da tabela como se fossem atributos da nossa classe, classe->atributo.
• Outra diferença é na forma de carregar os models. Pelo padrão do CodeIgniter, tínhamos que carregar os models toda vez que precisássemos utilizá-los (ex: $this->load->model(‘modelname’)). Agora basta instanciar o model como um objeto, pois o Doctrine tem a permissão de auto carregar os models.
• Não foi preciso criar o método “save” dentro do nosso model, o Doctrine disponibiliza métodos genéricos a partir da classe pai de cada model, a “Doctrine_Record”.

Agora acesse: http://localhost/codeigniter/index.php/usermanager/user_test

Depois acesse seu banco de dados e perceba que os 2 registros foram gravados na tabela user.

Agora eu gostaria de saber do vocês, o que acharam do tutorial? Dúvidas? Críticas? Sugestões?

Pra quem tiver interesse em baixar:

- Download Notepad_v0.1_20100527_ASNeto.apk (clique com o direito, e “Salvar destino como…”)

- Download do Código Fonte

Mas, voltando ao assunto, andei procurando WebServices públicos pra desenvolver aplicações de consulta pelo Android. Tive umas ideias e acredito que vou conseguir colocar algumas em prática. Ontem então eu comecei brincando com um aplicativo que até já existe no Market, mas fiz como hobby. Criei um aplicativo para consultar o endereço a partir de um CEP.

Aplicação bem simplória, o usuário seta o CEP, o sistema procura na internet, processa a informação e exibe o resultado. Criei para brincar e mostrar algumas coisas aqui. Como fonte de dados, usei o serviço do BuscarCEP que me fornece o resultado em String ou XML. Optei pelo XML e precisei usar a biblioteca jDom para processar o XML. Isso deixou a aplicação um tanto grande (para os padrões do Android) e depois quero pesquisar pra ver se encontro algumas soluções mais leves.

- Download BuscarCEP_v0.1.0-20100527.apk (clique com o direito, e “Salvar destino como…”)

- Download do Código Fonte

Uma coisa legal que fiz nessa aplicação foi usar reflexão. Isso aqui é puramente Java e pode ser usado em qualquer aplicação. Após ler o XML eu setei os valores lidos em um ValueObject (VO) que continha propriedades com os mesmos nomes das tags do XML. Dai pra chamar o método “set…” do VO, eu fiz assim:

// ... código antes ...
// Instância do meu VO
CepModel cepModel = new CepModel();
// Pega o Elemento root do XML
Element root = doc.getRootElement();
// Pega um filho chamado "retorno"
Element retorno = root.getChild("retorno", root.getNamespace());
// Pega os filhos do "retorno"
List cepData = retorno.getChildren();
 
// Itera sobre cada filho
for (int rx = 0; rx < cepData.size(); rx++)
{
	// Pega o valor do filho
	String data = cepData.get(rx).getText();
	// Pega o nome do filho.
	// Esse cara que vai ser usado pra chamar o método "set"
	String methodName = cepData.get(rx).getName();
	// Aqui eu formato ele para ficar com a inicial maiúscula e
	// concatenar o "set" na frente, ficando, por exemplo "setLogradouro"
	methodName = "set" + methodName.substring(0, 1).toUpperCase()
		+ methodName.substring(1, methodName.length());
 
	// Aqui que começa a ficar legal
	// Esse array define qual o tipo de dado de cada parâmetro que será
	// passado para o método, no meu caso uma String
	Class partypes[] = new Class[1];
	partypes[0] = String.class;
 
	// Esse array contém os valores de cada parâmetro que será passado para
	// o método, neste caso 1
	Object arglist[] = new Object[1];
	arglist[0] = data;
 
	// Aqui eu digo qual o nome do método que eu quero chamar, passando
	// os tipos de valores
	Method setMethod = cepModel.getClass().getMethod(methodName, partypes);
	// Aqui é a instância do meu VO
	Object instance = cepModel;
	// E aqui eu chamo o método "set"
	setMethod.invoke(instance, arglist);
}

Gosto de explorar esses recursos do Java. Sei que existem outras formas de se fazer isso, talvez até com uma melhor performance, mas o objetivo é explorar e descobrir recursos.

Certamente vou seguir fazendo uns programinhas pro Android e assim que eles ficarem estáveis, eu posto aqui. Ainda não desisti do meu app pro Twitpi, assim que ele ficar bom eu faço um post sobre ele.

Até a próxima.

Bom, nunca fui bom com as palavras e a minha idéia com o blog não é sair escrevendo sobre mim ou coisa parecida. Mexo com computadores desde que eu tinha uns 10 anos e ao longo desse tempo fui aprendendo muita coisa. Eu DETESTO ensinar às pessoas a usar um computador, os motivos são vários e não merecem ser comentados aqui. Apesar disso, eu gosto muito de ensinar sobre o que eu realmente gosto de fazer, que é programação. Nunca tive nenhuma experiência com didática e acredito que o blog vai me trazer um grande aprendizado.

Bom, resumindo, minha idéia com este blog é registrar etapas que eu tenha passado ou simplesmente postar sobre tecnologias recentes. Atualmente tenho mexido com PHP, CodeIgniter, Java, JSF, Richfaces, Hipernate, JPA, Spring, Struts, Velocity e Android. Tenho juntando algum material para poder iniciar o blog, então logo logo vou postar alguma coisa mais técnica por aqui.

Só me apresentando: me chamo Alexandre, tenho 23 anos, me formei no curso de Análise e Desenvolvimento de Sistemas pela Universidade Católica de Pelotas no ano de 2009 e tenho ainda um curso técnico de Sistemas de Informação pelo antigo CEFET-RS, atual IF-SUL, onde tive minhas primeiras experiências na área de programação. Profissionalmente, comecei a trabalhar em 2008 na Create, uma agência digital de Pelotas. Programava em PHP e toda aquela leva de coisas que os sites institucionais e sistemas trazem: HTML, CSS, JavaScript, jQuery, bla bla bla. Pouco depois tive a oportunidade de fazer um processo seletivo com treinamento, o qual obtive sucesso, e entrei na Gestum. Foi lá que realmente aprendi a programar em Java usando o framework JSF. Atualmente trabalho na Voiza como desenvolvedor Java.

Quero ver se pratico aqui o meu Inglês também, então dependendo do tamanho do post, quero ver se consigo fazer uma versão em inglês. Vale lembrar também que eu nunca mexi no WordPress, então to aprendendo ainda e pode ser que as vezes apareçam uns testes meus por ai! hehehe

Para entrar em contato comigo:

alexandre.sneto@gmail.com

twitter.com/alexandresneto

msn: alexandre@ftlan.com (preciso mudar isso)