Thiago Mata

Resolvendo Problemas com Aspas Duplas do Zend_Db_Table_Abstract

2011-09-09T14:02:00.000-07:00

Resumo,

Quando você tentar apontar o Zend_Db_Table_Abstract do Zend Framework com o Oracle, para gerar comandos SQL é possível que você enfrente o mesmo problema que nós enfrentamos, aspas duplas aparecem e fazem seus comandos SQL inválidos. Para resolver isso adicione a seguinte linha:

resources.db.params.options.autoQuoteIdentifiers = 0

no seu application.ini e seja feliz.

Versão Longa,

Quando o Zend_Db_Table_Abstract gera erros ao tentar executar seus comandos SQL triviais, gerados automaticamente, qual é o 1º passo? Eu costumo gerar o assemble() do comando SQL para poder testa-lo diretamente no banco de dados.

Como o problema que temos é com qualquer método, então testamos no mais simples, sobrescrevendo o getAll e fazendo isso:

public function getAll($where = null, $order = null, $count = null, $offset = null)

{

var_export( $this->select()->assemble() );

exit();

}

Então obtemos:

SELECT "tb_estado".* FROM "db_projeto"."tb_estado"

Sabemos agora qual é o problema: As consultas geradas automaticamente pelo Zend estão colocando aspas duplas no nome das tabelas e do schema, o que não é aceito no Oracle.

Após pesquisar um pouco achei esse link http://doczf.mikaelkael.fr/1.10/pt-br/zend.db.select.html que informa:

O método quoteIdentifier() usa aspas no SQL para delimitar o identificador, o que deixa claro que ele é um identificador de uma tabela ou coluna e não parte da síntaxe SQL.

Agora qual é o problema: As consultas geradas automaticamente pelo Zend estão colocando aspas duplas no nomes devido ao método _quoteIdentifier, que funciona do seguinte modo:

http://www.tig12.net/downloads/apidocs/zf/Db/Adapter/Abstract.php.source.html#line1016

1009     /**
1010      * Quote an identifier.
1011      *
1012      * @param  string $value The identifier or expression.
1013      * @param boolean $auto If true, heed the AUTO_QUOTE_IDENTIFIERS config option.
1014      * @return string        The quoted identifier and alias.
1015      */
1016     protected function _quoteIdentifier($value, $auto=false)
1017     {
1018         if ($auto === false || $this->_autoQuoteIdentifiers === true) {
1019             $q = $this->getQuoteIdentifierSymbol();
1020             return ($q . str_replace("$q", "$q$q", $value) . $q);
1021         }
1022         return $value;
1023     }

O nosso problema agora tem um foco bem mais específico. Como fazer o atributo protegido _autoQuoteIdentifiers ser falso. Logicamente se o atributo fosse público ou ao menos tivesse um setAutoQuoteIndentifiers ou algo similar, estaria agora resolvido o problema, na nossa classe pai que herda o Zend_Db_Table_Abstract, algo muito parecido com:

public function init()

{

$this->_db->setAutoQuoteIndentifiers( false );

}

Mas, para nossa tristeza e agonia esse método setter não existe. Então precisamos descobrir como esse atributo recebe um valor.

Fazendo uma busca na classe, vemos que esse atributo pode ter seu valor atribuído caso ele venha no Array que é recebido no método construtor da classe

http://www.tig12.net/downloads/apidocs/zf/Db/Adapter/Abstract.php.source.html#line240

238
239         // obtain quoting property if there is one
240         if (array_key_exists(Zend_Db::AUTO_QUOTE_IDENTIFIERS, $options)) {
241             $this->_autoQuoteIdentifiers = (bool) $options[Zend_Db::AUTO_QUOTE_IDENTIFIERS];
242         }
243

Tentando entender como essa variável $options é montada, vemos que essa variável é um Array que é inicializado com os valores padrões:

185         $options = array(
186             Zend_Db::CASE_FOLDING           => $this->_caseFolding,
187             Zend_Db::AUTO_QUOTE_IDENTIFIERS => $this->_autoQuoteIdentifiers
188         );

Mas que tem esses valores alterados conforme os elementos que são recebidos no campo "options" do $config. Sendo $config o Array que é recebido no construtor.

190
191         /*
192          * normalize the config and merge it with the defaults
193          */
194         if (array_key_exists('options', $config)) {
195             // can't use array_merge() because keys might be integers
196             foreach ((array) $config['options'] as $key => $value) {
197                 $options[$key] = $value;
198             }
199         }

Procurando então em que local do Zend_Db_Table_Abstract que é instanciado o atributo $this->_db

Chegamos nas seguintes linhas:

575     /**
576      * @param  mixed $db Either an Adapter object, or a string naming a Registry key
577      * @return Zend_Db_Table_Abstract Provides a fluent interface
578      */
579     protected function _setAdapter($db)
580     {
581         $this->_db = self::_setupAdapter($db);
582         return $this;
583     }

Seguindo o rastro, vamos ao método _setupAdapter:

594
595     /**
596      * @param  mixed $db Either an Adapter object, or a string naming a Registry key
597      * @return Zend_Db_Adapter_Abstract
598      * @throws Zend_Db_Table_Exception
599      */
600     protected static function _setupAdapter($db)
601     {
602         if ($db === null) {
603             return null;
604         }
605         if (is_string($db)) {
606             require_once 'Zend/Registry.php';
607             $db = Zend_Registry::get($db);
608         }
609         if (!$db instanceof Zend_Db_Adapter_Abstract) {
610             require_once 'Zend/Db/Table/Exception.php';
611             throw new Zend_Db_Table_Exception('Argument must be of type Zend_Db_Adapter_Abstract, or a Registry key where a Zend_Db_Adapter_Abstract object is stored');
612         }
613         return $db;
614     }

Vemos então que esse método consulta o Zend_Registry, o que já era esperado. Sem querer entrar na complexidade desse Registry, nós sabemos que o Zend_Registry do Banco de Dados é informado no application.ini. É lá que informamos dados como login, senha, nome do banco de dados, etc. Então, será que os dados que o construtor do Zend_Db_Table_Abstract apenas lê os dados vindos do application.ini, na parte dos "resources.db"?

Para testar essa hipótese eu vou imprir o $config do construtor do Zend_Db_Table_Abstract. Como qualquer alteração feita no código do Zend Framework isso é apenas para auxiliar o nosso entendimento e deverá ser desfeita em breve.

Ao adicionar no construtor a seguinte linha:

public function __construct($config)

{

var_export( $config );

exit();

// (...)

Obtemos o seguinte resultado:

array (

'host' => 'banco_do_projeto',

'username' => 'usuario_do_servidor',

'password' => '******',

'dbname' => 'db_projeto',

'charset' => 'utf8',

'profiler' =>

array (

'enabled' => '1',

)

Precisamos adicionar uma linha no nosso application.ini para testar se essa chegará até o $config. Mas qual seria o valor dessa linha. Por semelhança aos demais elementos que chegaram, deve ser algo similar a resources.db.params.options.xxxxxxxxxxx = 0. Mas, para encontrarmos o valor que desejamos, precisamos saber qual é o valor da chave. Esse valor nós podemos ver aqui:

http://www.tig12.net/downloads/apidocs/zf/Db/Adapter/Abstract.php.source.html#line187

185         $options = array(
186             Zend_Db::CASE_FOLDING           => $this->_caseFolding,
187             Zend_Db::AUTO_QUOTE_IDENTIFIERS => $this->_autoQuoteIdentifiers
188         );

Usando o CRTL+Click da IDE, já fui direto para a declaração desta constante, conforme:

http://www.tig12.net/downloads/apidocs/zf/Db.php.source.html#line48

const AUTO_QUOTE_IDENTIFIERS = 'autoQuoteIdentifiers';

Logo a nossa nova linha no application.ini, deve ser:

resources.db.params.options.autoQuoteIdentifiers = 0

Obtemos o seguinte resultado:

array (

'host' => 'banco_do_projeto',

'username' => 'usuario_do_servidor',

'password' => '******',

'dbname' => 'db_projeto',

'charset' => 'utf8',

'options' =>

array (

'autoQuoteIdentifiers' => '1',

'profiler' =>

array (

'enabled' => '1',

)

Esse novo elemento no $config vai alterar o atributo protegido _autoQuoteIdentifiers retirando as aspas dos SQL gerados e resolvendo o nosso problema.

Espero que isso tenha ajudado.

Um grande abraço.

O Template do InepZend

2011-05-16T08:14:00.000-07:00

Ainda sem nome próprio, o template do Inep Zend Framework tem sido uma das partes mais desafiadoras e excitantes de todo o projeto. Por isso resolvi começar falando logo deste componente.

Provavelmente, você deve estar com alguma(s) das seguintes indagações abaixo:

PHP precisa de Template?
Smarty já não é bom o bastante?
Será que vou ter de aprender mais uma linguagem de Template?

PHP precisa de Template?

É possível desenvolver bons projetos, de alta complexidade em PHP sem utilizar templates? Sim. Tanto que o Zend Framework vem nativamente sem nenhuma camada de Template. Mas então, qual é a vantagem do Template? Em linhas gerais, ao se manter a complexidade lógica da aplicação separada do controle da apresentação se reduz o risco de que mudanças no layout gerem impacto sob a lógica da aplicação e vice-versa. A vantagem da camada de Template é bem similar a vantagem de se dividir o código em camadas. Se reduz o acoplamento sem perder a coesão. Com o uso de Templates, o impacto de alterações se torna menor e se facilita identificar o local responsável por um erro. Os pontos negativos também são similares a divisão de camadas, se tem um aumento de complexidade do projeto e um provável aumento no tempo de processamento.

Se a sua empresa tem a divisão entre programadores e designers é quase certo que você precisa de fazer uso de uma camada de Template ( mesmo que não esteja fazendo isso ). Se o seu projeto faz uso de mascaras nos elementos de entrada, tais como mascaras para entradas de valores em dinheiro, entradas de datas, etc., pense seriamente no impacto de alterar essa sua mascara para funcionar num navegador novo, por exemplo.

Um outro problema freqüente é que os programadores não se preocupam tanto com a qualidade do HTML gerado. Basta tentar validar o seu projeto com alguma das ferramentas disponíveis, tais como o http://validator.w3.org/ para perceber isso. É muito comum que o HTML válido que o designer passa para a equipe de programação, é alterado várias vezes pela equipe de programação, até que passa a apresentar vários erros de HTML, que são simplesmente ignorados pelos programadores. A complexidade de algumas solução de Template, dificultam ainda mais o controle sobre o HTML desenvolvido. Uma solução clássica de cabeçalho e rodapé gera um problema muitas vezes difícil de resolver. Não será intuitivo, para quem for dar manutenção nos seus arquivos, saber qual é, de todos os arquivos que contém HTML, aquele que fecha a tag da tabela que é aberta no arquivo atual.

Finalmente uma camada de Template pode facilitar a utilização de soluções complexas de modo mais transparente e padronizado. Por exemplo, transformar um formulário de submissão tradicional POST em Ajax pode ser automatizado pela ferramenta desde que informado algum atributo específico. Evita-se assim a criação de várias soluções diferentes para o mesmo problema que além de serem um problema para a manutenção do projeto é um desperdício do tempo de desenvolvimento do programador. Mais argumentos sobre isso você pode encontrar aqui.

Smarty já não é bom o bastante?

Entre as soluções disponíveis de Templates para PHP, o Smarty certamente é a mais popular. O Dwoo intenta ser uma versão um pouco mais moderna do Smarty, mas mantendo o máximo possível de compatibilidade e mantém também vários dos problemas descritos abaixo. As outras soluções encontradas, tais como o Sigma, Twig, Haanga também apresentam alguns dos problemas citados no caso do Smarty.

Os principais motivos que nos levou a decidir não utilizar o Smarty foram:

Não disponibilizar validação do HTML gerado;

Para o Smarty, assim como no PHP nativo, o resultado gerado é um texto. Se o texto gerado é um HTML ou não, é um controle que é feito apenas pelo programador. Deste modo, caso o HTML gerado não seja válido, o Smarty não irá fazer nenhum tipo de alerta a respeito, deixando o resultado inválido ser entregue ao usuário.

Não ser XML;

Praticamente qualquer IDE é capaz de fazer uma validação de XMLs. O padrão XML é conhecido tanto por designers quanto por programadores e é o formato padrão em que o XHTML é escrito. Nada faz mais sentido de que o próprio Template seja também em XML.

Não ser flexível para novas funcionalidades;

O Smarty, segundo a avaliação da nossa equipe, se mostrou pouco flexível para a criação de novas funcionalidades. Chegamos até a editar algumas das expressões regulares do Smarty para tentar deixar o comportamento dele mais flexível antes de decidirmos partir para uma solução própria.

Não ser orientado a objetos.

Por ter sido desenvolvido para PHP4. O Smarty não faz uso dos recursos de orientação a objetos do PHP5. Um componente de template que faça uso de orientação a objetos viabiliza uma personalização e compreensão mais fácil do código em execução, mais flexibilidade na geração de tags personalizadas e ainda a geração e alteração de telas por métodos DOM

Será que vou ter de aprender mais uma linguagem de Template?

Agora que espero que você já esteja convencido de que precisa de algum Template mais moderno que o Smarty, você deve estar sofrendo com o problema de ter de aprender uma nova gramática de Template. Essa preocupação é perfeitamente compreensível, pois cada ferramenta de Template cria uma versão tão personalizada "para melhor" das tags do HTML. Então, passar a utiliza-la é quase como aprender um HTML diferente. As confusões são inevitáveis assim como o ódio das alterações de nome sem sentido.

Uma das metas nessa nossa nova ferramenta de Template foi, no máximo possível, não criar tags novas. Então todas as tags do HTML5 funcionam exatamente como são no HTML5. Exatamente isso, escreva um HTML válido e ele já é um Template válido. Se você escrever um HTML inválido o PHP irá gerar uma Exception informando qual regra do HTML5 foi quebrada. Isso mesmo, o PHP através do Template faz validação Server Side do HTML gerado pelo Template. Na versão atual da ferramenta essa validação é obrigatória mas devemos deixa-la opcional para que possa deixar o sistema mais rápido em produção, etc.

Mas a vantagem de uma ferramenta de Template é exatamente seu dinamismo então, foi inevitável se criar as tags de repetição, de condição, etc. Então, foram sim criadas tags de template que provavelmente você terá que aprender. A vantagem é que todas essas novas tags são Classes PHP bem documentadas e com exemplos. Conforme pode ser visto aqui.

Na verdade todas as tags do Template são classes PHP. Inclusive as tags do HTML5, tornando assim possível a validação do HTML conforme citado acima. Transformamos cada Template XML num arquivo PHP, usando o componente Xml2Php, fazendo cache, usando o componente de Cache, que monta uma arvore de objetos que, quando desenhada, monta uma página XHTML.

Então temos aqui todas as tags do HTML5 escritas no formato de classes bem documentadas. Mesmo que você não tenha se convencido da idéia dos Templates ou não tenha gostado da nossa solução, pode ser útil como ferramenta de pesquisa.

Todas as tags podem ser estendidas, podendo você ter tags específicas do seu projeto. Por exemplo essa tag Numero estende a tag Input colocando uma mascara Javascript.

Então, resumindo tudo num exemplo: esse template, vira esse arquivo php que quando interpretado é validado e monta dinamicamente uma página XHTML5.

Espero que tenham gostado do nosso Template. Em breve devemos disponibilizar tutoriais para explicar melhor item a item dentro do site do projeto. Esse post foi mais um making-off das motivações e decisões que levaram o projeto até onde ele está.

Abraços,

Thiago Mata.

Algumas perguntas e repostas:

Rafael Barbosa disse...

Sem querer desmerecer o projeto, mas pelas motivações e implicações colocadas eu não entendi porque não utilizar um template engine pronto. O Twig, por exemplo, tem tudo que você precisa e já está pronto.

Sem contar que transformar markup em objetos pra transformar em markup de novo simplesmente pra garantir que esteja bem formado me parece MUITO overkill.

Eu trabalhei muito tempo no governo e sei que é difícil conseguir agregar um ferramental novo ao trabalho, mas ainda acho que vale o esforço de tentar utilizar algo que já está estável e é amplamente aceito pela comunidade do que construir algo do zero.

Thiago Mata responde...

Primeiramente seu comentário é muito pertinente. A resposta que eu vou lhe passar devo colocar na própria documentação do projeto mas talvez ainda assim faça um adendo no post falando disso.

Conforme você já deve ter notado, a solução que fizemos foi muito similar ao Jsf http://exadel.com/web/portal/jsftags-guide, Seam, ColdFusion, JLibs http://code.google.com/p/jlibs/wiki/XMLDocument, então vou evitar ser repetitivo e dizer que os pontos positivos e negativos dessas soluções são bem próximos. Basta uma busca sobre Jsf ou Jlibs e você verá pessoas defendendo e apoiando conforme o contexto. Apenas ressaltando que na nossa implementação, foram mantidas os nomes e os atributos das tags do html.

Apesar do custo das conversões Xml => OO => Xml ser de fato um custo grande, a diferença em termos de tempo resposta, mesmo quando fizemos simulações de vários milhares de acessos simultâneos, não foi tão grande ao ponto de ser considerado impeditivo, tendo em vista o porte das máquinas que temos. Mas compreendo que isso pode não ser o caso em outras empresas.

Utilizar esse recurso de Xml => OO => Xml nos permite muito mais do que apenas validar o Xhtml, esse foi um dos argumentos do post que já estava muito extenso. Esse argumento se mostrou importante aqui na empresa por que foi uma das reclamações que nossos usuários finais fazem dos nossos sistemas. Como estamos ainda tendo que trabalhar com fabricas de softwares, controlar a qualidade do xhtml gerado é essencial. Lembre-se que temos sistemas em que os usuários são deficientes visuais ou com inabilidades motoras onde uma página html mal feita pode ser impeditivo ao uso.

Dentre outras vantagens dessa solução temos o encapsulamento de componentes complexos de tela em objetos. Podemos ter as tags personalizadas como etc. E, a mesma validação que funciona nas tags do xhtml, irá validar se os campos de cada uma dessas tags foram adequadamente preenchidos, assim como já está funcionando com as tags de template. A criação dessas tags personalizadas pode ser feita utilizando outros templates combinados com comandos DOM, ou fazendo uso apenas de objetos e DOM, etc. Tudo isso utilizando as vantagens de uma organização OO. Essa capacidade de encapsulamento de complexidade e padronização de arquitetura de modo intuitivo no template foi uma das melhorias solicitadas para a nossa equipe.

Se você avaliar o exemplo da tag personalizada Number que utilizei no post, irá notar que uma tag no meio do conteúdo adicionou um script no head. Então, conforme pode ser visto nesse exemplo, as tags podem interagir entre si, adicionando ou alterando o comportamento de tags anteriores. Com isso nós podemos fazer, por exemplo, páginas que façam carga apenas dos arquivos javascript e css que forem ser utilizados. Podemos também fazer facilmente que uma tag especial seja a soma dos valores de outras tags, a média dos valores, etc. sem exigir conhecimento de javascript.

Uma das idéias das próximas é viabilizar a "adequação" do html de resultado para o navegador do cliente. O programador / designer continuará escrevendo HTML5 e será de responsabilidade do framework fazer as "correções" necessárias para funcionar nos browsers não modernos.

Por último, tendo em vista que temos uma versão server side da página do usuário, podemos armazena-la na sessão, e então fazer uma sincronia das alterações usando ajax. Em outras palavras, podemos fazer manipulações server side no objeto tela, a partir de eventos de tela enviados ao servidor, que depois é sincronizado no cliente via ajax. Esse passo ainda está em iniciação no Inep Zend mas no Coruja Php Framework já conseguimos isso com sucesso. Chegamos a desenvolver uma planilha similar ao Excel / Calc utilizando esta técnica com toda lógica de negócio necessária para a interpretação das fórmulas e alteração em cascata do valor dos campos no Server Side.

Além de tudo, não obrigamos nossa equipe a utilizar esse template o tempo todo. Conforme foi dito mantemos a compatibilidade do tudo que já funcionava no Zend, inclusive o phtml. Então, caso numa página ou layout o uso do template se mostre desnecessário ou inadequado, o programador pode fazer uso da solução padrão do Zend. Pode-se até pensar de maneira invertida, utilizando sempre phtml e ter essa ferramenta de template caso se deseje fazer alguma página de maior complexidade.

Espero ter esclarecido,
Thiago Mata.

Rafael Barbosa disse...

Caro Thiago,

posso postar no seu blog esse comentário depois sem problema.

Eu entendo o embasamento que você teve de outras ferramentas, e acho válida a iniciativa de querer melhorar as ferramentas de trabalho. O que me preocupa é o tempo gasto com algo que, a meu ver, tem muito mais desvantagens do que vantagens.

A parte da validação de markup não deveria ser responsabilidade da framework e pode ser remediada de N formas. A mais simples delas é exigir a validação das páginas com as ferramentas da w3c na rotina de testes/homologação do seu sistema. Isso é muito simples de justificar e eu julgo necessário mesmo tendo a validação interna no pré-processamento da requisição. Logo, esse problema de validação tem uma solução que não necessita escrever 1 linha de código.

O custo da transformação do markup para objeto se torna linear se vc usar algum ferramenta (por mais simples que seja) de cache. Eu não disse que o custo era ALTO e sim DESNECESSÁRIO (usei o termo OVERKILL). O que você vai ter com isso é mais um ponto de falha, mais um módulo para dar manutenção e mais um pedaço da sua arquitetura para documentar e testar sem ter o ganho que isso deveria te proporcionar.

Quanto às tags personalizadas elas já existiam no Smarty (apesar de ser um inferno extender aquilo) e existem no Twig (que na minha humilde opinião é a melhor engine de template que existe) e em outras ferramentas. Talvez o que exista no seu caso seja uma preferência em usar tags fechadas por <> (o que eu não acho legal, mas entendo ser outra questão), nesse caso basta alterar uma dessas bibliotecas para utilizar as tags como você gosta, assim você não precisa reinventar a roda.

Guardar a página do usuário em sessão e atualizar via ajax. Isso realmente é algo que você deveria repensar antes de implementar. Alguns motivos para isso:
1 - Você já tem todo o DOM bonitinho na tela do seu usuário ( em JavaScript). Ter isso em sessão é simplesmente duplicar uma informação, uma vez que o servidor não pode fazer muita coisa com ela.
2 - Tudo que existir na tela (client) vai ter que de alguma forma sincronizar de volta com o servidor. Isso é completamente desnecessário, visto que o browser já armazena o estado da tela e em último caso você pode armazenar isso em um cookie via javascript e poupar uma requisição.
3 - Quando você mandar do servidor de volta todo o markup pra tela do cliente você vai precisar carregar de novo todos os binds de objetos no javascript (inclusive os que não mudaram), o browser vai ter que renderizar de novo a página toda. (O cache ajuda, mas não vai fazer milagre)
4 e mais importante: Se você, de alguma forma, for atualizar pedaços da interface com a resposta do servidor em vez de atualizá-la por completo, qualquer framework de javascript faz esse trabalho de forma stateless/rápida e ainda te permite alterar o history do browser com o pushState sem quebrar o botão de voltar.

A parte de corrigir o markup de acordo com a versão do browser faz sentido, mas dificilmente você vai esbarrar com uma situação em que alterar o html resolva uma incompatibilidade que você não consiga resolver com alguma camada de abstração pronta em javascript/css.

Mais uma vez, eu aprecio a iniciativa e pelo nível de complexidade de uma ferramenta dessas eu acredito que você e os membros da sua equipe sejam ótimos programadores, mas acho que a força de trabalho de vocês deveria ser utilizada pra construir algo novo e melhor e não ficar reescrevendo ferramentas que já existem.

Dá uma olhada do que tem sido feito nos projetos da sensio-labs. Especialmente o Symfony 2 e o Doctrine 2. Eles estão escrevendo as bibliotecas mais avançadas em php 5.3 que existem. Vale a pena dar uma olhada e tentar participar dessa evolução da das ferramentas e da linguagem junto com a comunidade.

Atenciosamente,
Rafael Barbosa

Thiago Mata responde...

Gostei dos seus comentários como sempre,

Eu entendo o embasamento que você teve de outras ferramentas, e acho válida a iniciativa de querer melhorar as ferramentas de trabalho. O que me preocupa é o tempo gasto com algo que, a meu ver, tem muito mais desvantagens do que vantagens.

Ainda não vi tantas desvantagens. Replicar as tags do HTML foi um trabalho massante, de fato, mas feito com baixa complexidade e em relativamente pouco tempo. Bastou lermos a especificação do Mozilla http://developer.mozilla.org/en/HTML/Element/ e como eu te falei não tem tanto impacto na performance. A complexidade do código não é tão grande e pretendemos fazer bons testes com ele com PHPUnit o que deve reduzir consideravelmente a chance de algum erro. Então não vi as desvantagens.

A parte da validação de markup não deveria ser responsabilidade da framework e pode ser remediada de N formas. A mais simples delas é exigir a validação das páginas com as ferramentas da w3c na rotina de testes/homologação do seu sistema. Isso é muito simples de justificar e eu julgo necessário mesmo tendo a validação interna no pré-processamento da requisição. Logo, esse problema de validação tem uma solução que não necessita escrever 1 linha de código.

Estou certo que não preciso te lembrar que todas as páginas são dinâmicas e testar todas as combinações pode ser um trabalho sem fim. Garantir continuamente a qualidade do HTML é um ponto positivo. O teste de validação vai continuar existindo mas será feito sempre em algumas poucas das saídas possíveis. Além do que as mensagens de erro do Framework podem ser mais claras do que a validação externa como mostrar em qual arquivo de Template o erro aconteceu. Lembrando que essa validação de atributos obrigatórios, valores default, etc. deve existir para as tags personalizadas então estamos reaproveitando esse recurso para validar também as tags do HTML.

Quanto às tags personalizadas elas já existiam no Smarty (apesar de ser um inferno extender aquilo)

INFERNO!!!

e existem no Twig (que na minha humilde opinião é a melhor engine de template que existe) e em outras ferramentas. Talvez o que exista no seu caso seja uma preferência em usar tags fechadas por <> (o que eu não acho legal, mas entendo ser outra questão), nesse caso basta alterar uma dessas bibliotecas para utilizar as tags como você gosta, assim você não precisa reinventar a roda.

Até onde eu sei. O Twig ainda segue uma linha de templates de arquivos incluindo arquivos que já vi várias vezes fugindo de controle. Mas prometo que vou avalia-lo mais a fundo. Se ele se mostrar uma solução que venha a atender nossas necessidades nós poderemos passar a utiliza-lo ou deixa-lo como uma opção de template alternativa.

Guardar a página do usuário em sessão e atualizar via ajax. Isso realmente é algo que você deveria repensar antes de implementar. Alguns motivos para isso:
1 - Você já tem todo o DOM bonitinho na tela do seu usuário ( em JavaScript). Ter isso em sessão é simplesmente duplicar uma informação, uma vez que o servidor não pode fazer muita coisa com ela.
2 - Tudo que existir na tela (client) vai ter que de alguma forma sincronizar de volta com o servidor. Isso é completamente desnecessário, visto que o browser já armazena o estado da tela e em último caso você pode armazenar isso em um cookie via javascript e poupar uma requisição.
3 - Quando você mandar do servidor de volta todo o markup pra tela do cliente você vai precisar carregar de novo todos os binds de objetos no javascript (inclusive os que não mudaram), o browser vai ter que renderizar de novo a página toda. (O cache ajuda, mas não vai fazer milagre)
4 e mais importante: Se você, de alguma forma, for atualizar pedaços da interface com a resposta do servidor em vez de atualizá-la por completo, qualquer framework de javascript faz esse trabalho de forma stateless/rápida e ainda te permite alterar o history do browser com o pushState sem quebrar o botão de voltar.

1. Ter 100kb a mais para cada sessao de cada usuário logado não é exatamente um problema terrível. Lembre-se que essa página já existe como arvore de objetos no servidor então eu só serializo e salvo na sessão. No ambiente de produção muitas vezes os "arquivos" da sessão ficam numa area da memória RAM. Então fica muito realmente rápido. Podemos também guardar esse dado serializado em outros lugares além da sessão como no banco ou num arquivo separado, etc.

2. Não entendi. Tenho a impressão que você não entendeu exatamente como nós fizemos essa sincronia. As operações nesse contexto vão acontecer no servidor. Veja GWT, que é algo muito similar a isso.

3. Não vamos mandar de volta uma versão toda nova da tela. Apenas receber um json com o que mudou em quais tags. Novamente recomendo você dar uma boa olhada no GWT.

4. Pretendo sim utilizar algum framework Javascript para fazer essa comunicação com o servidor. Mas isso não impede de precisamos de um servidor capaz de receber o evento e saber quais tags devem ser alteradas e quais devem ser seus novos conteúdos etc.

Thiago Mata.

Rafael Barbosa disse...

Caro Thiago,

http://developer.mozilla.org/en/HTML/Element/ e como eu te falei não tem tanto impacto na performance. A complexidade do código não é tão grande e pretendemos fazer bons testes com ele com PHPUnit o que deve reduzir consideravelmente a chance de algum erro. Então não vi as desvantagens.

Ter testes unitários vai mesmo reduzir bugs e te ajudar a dar manutenção, o que não quer dizer que essa manutenção deixe de existir. Como eu disse, como qualquer parte do sistema, tem que ter uma razão pra estar lá senão não vale o esforço de manutenção.

Manter o HTML válido sempre é interessante, mas eu acho que isso deveria ser uma tarefa executada ao empacotar sua aplicação e não a cada request. Uma solução mais limpa (e que não exigiria a recriação das views da sua aplicação) seria a criação de testes de aceitação pra cada uma das funcionalidades onde, além de executar o teste de aceitação da especificação você utilizasse os webservices da W3C para validar o markup gerado ao final do teste. Dá um pouco de trabalho adaptar o PHPUnit pra fazer esse tipo de teste mas o tempo que isso vai te poupar a longo prazo é absurdo!

Como todo código extensível (e isso inclui o próprio php) se você não definir um padrão de uso os arquivos vão fugir do controle. Como exemplo o ministério da saúde migrou de phtml para twig. Os arquivos em si não mudaram, só o conteúdo, o twig não exige nenhuma extensão específica. Dessa forma a sanidade em relação aos arquivos foi mantida.

3. Não vamos mandar de volta uma versão toda nova da tela. Apenas receber um json com o que mudou em quais tags. Novamente recomendo você dar uma boa olhada no GWT.

1 - Não é um problema terrível se você precisar mesmo disso. Eu ainda não entendi a vantagem de se passar a lógica do cliente para o servidor.

2 e 3 - Realmente eu tinha entendido diferente. Dessa forma realmente faz sentido.

4 - Nesse caso depende muito do que você vai precisar fazer. Eu acho que apesar de não existirem grandes problemas, a priori, de manter a página em sessão acredito que para boa parte dos casos não existe essa necessidade. Movimentar coisas na tela por exemplo não precisaria chegar no servidor. Pode ser que para o tipo de aplicação que você desenvolva aí isso faça sentido e eu esteja falando besteira =)

Atenciosamente,
Rafael Barbosa

Thiago Mata responde...

Gostei dos seus comentários como sempre,

Acredito que você tenha entendido muito bem a solução. Sei que ela apresenta uma complexidade relativamente alta que pode em alguns casos não compensar o uso. Mas conforme você mesmo citou existem casos e casos. Não digo que essa solução precisa / deva ser utilizada em qualquer caso. Na verdade, não acredito que nenhuma solução deva ser utilizada em qualquer caso, num complexo de "bala de prata".

Mas conforme os exemplos já citados de GWT, JSF, JLIBS, SEAM, etc. existem contextos onde fazer essa conversão se justifica. Existem ainda cenários que utilizar essa solução não é necessário mas pode parecer interessante. Com o framework maduro e já bem otimizado, utilizar essa solução em contextos mais simples pode ser uma boa opção, pensando-se nos ganhos já citados. Novos pontos positivos serão criados a cada dia conforme enriquecemos a solução. Certamente terá pontos negativos, como qualquer decisão. Talvez quando eu tiver exemplos da interação entre os arquivos de template sem os muitos includes, fique mais claro outros ganhos que a utilização desse tipo de solução venha a apresentar. A solução em SEAM, com componentes personalizados, foi muito bem aceita pela equipes, por exemplo, aumentou a produtividade, a padronização e a qualidade dos softwares desenvolvidos. Estamos tentando aprender com as soluções que deram mais certo e errado dentro do nosso cenário e gerar soluções adequadas ao mesmo.

Resumindo, o que estamos oferecendo aqui é uma opção de solução que temos desenvolvido para se adequar à nossa demanda e ao nosso cenário. Acreditamos que ela pode vir a ser útil em outros cenários também. Certamente ela não será a melhor solução em qualquer cenário mas talvez venha a ser uma boa opção para um cenário que vocês venham a encontrar.

Atenciosamente,

Thiago Mata.

Framework PHP - Inep Zend

2011-05-16T04:39:00.000-07:00

Olá colegas,

Como muitos já sabem tenho trabalhado bastante nesses dias na intenção de migrar para dentro do Zend Framework alguns componentes úteis que criamos para o Coruja Framework. Além disso, estamos criando algumas solução que visam melhorar a produtividade / qualidade dos softwares aqui da empresa, utilizando o Zend Framework. Muitas dessas soluções novas devem fazer o caminho reverso e terem uma versão dentro do Coruja Framework que seja independente do Zend Framework.

Dito isso, eu apresento a vocês o Inep Zend Framework. O projeto, apesar de ainda está numa versão bem preliminar, já está apresentado bons resultados e uma boa receptividade por quem o avalia. Entre suas principais funcionalidades estão:

Modelo Entidade Relacional mais prático, utilizando Anotações;
Zend Forms mais práticos, utilizando Anotações e métodos mágicos;
Possibilidade de se receber parametros, nos métodos das Controladoras;
Uma camada de Template bastante intuitiva, rica e flexível.

Pretendo detalhar melhor, em posts separados, cada uma desses componentes, e dos novos que venham a surgir. Comentários, críticas e sugestões serão sempre bem-vindos.

Espero que gostem,

Thiago Mata.

PhpUnit 3.4

2010-02-26T09:11:00.000-08:00

Como instalar o PhpUnit 3.4 no ubuntu.

# apt-get install php5 php5-dev
# pecl install xdebug
# pear channel-discover pear.phpunit.de
# pear install --alldeps phpunit/PHPUnit

Flash Slideshow feito em PHP lendo XML

2010-01-28T18:47:00.000-08:00

Estive precisando recentemente de criar uma galeria de imagens que tivessem alguns recursos interessantespara um site de um fotografo

Logicamente eu não queria ter de editar a galeria toda vez que ele quisesse adicionar uma nova foto ou alterar a apresentação. Pensando em fazer uma ferramenta que possibilite que o fotografo venha a editar a apresentação do seu slideshow ,sem exigir conhecimentos computacionais, eu criei um componente que lendo um XML numa formatação específica, que ainda não tem um schema para descreve-la, venha a criar um SWF.

O resultado é uma ferramenta que converte esse XML:

<...slideshow>
 <...slides>         
     <...slide time="70" >             
         <...image x="110"  y="320"  src="photo1.jpg"  wait="0"  stay="20"  fadein="20"  fadeout="20" />         
     <.../slide>         
     <...slide time="70" >             
         <...image x="310"  y="320"  src="photo5.jpg"  wait="10"  stay="20"  fadein="20"  fadeout="20" />         
     <.../slide>         
     <...slide time="100" >             
         <...image x="210"  y="220"  src="photo2.jpg"  wait="0"  stay="50"  fadein="20"  fadeout="30" />             
         <...image x="510"  y="220"  src="photo3.jpg"  wait="10"  stay="40"  fadein="20"  fadeout="30" />             
         <...image x="810"  y="220"  src="photo4.jpg"  wait="20"  stay="30"  fadein="20"  fadeout="30" />         
     <.../slide>         
     <...slide time="100" >             
         <...image x="210"  y="220"  src="photo2.jpg"  wait="0"  stay="20"  fadein="20"  fadeout="30" />             
         <...image x="510"  y="220"  src="photo2.jpg"  wait="10"  stay="20"  fadein="20"  fadeout="30" />             
         <...image x="810"  y="220"  src="photo2.jpg"  wait="20"  stay="20"  fadein="20"  fadeout="30" />             
         <...image x="1110"  y="220"  src="photo2.jpg"  wait="30"  stay="20"  fadein="20"  fadeout="30" />             
         <...image x="1410"  y="220"  src="photo2.jpg"  wait="40"  stay="20"  fadein="20"  fadeout="30" />         
     <.../slide>         
     <...slide time="160" >             
         <...image x="1000"  y="220"  src="photo2.jpg"  wait="0"  stay="80"  fadein="40"  'fadeout="40"/>  
     <.../slide> 
 <.../slides> <.../slideshow>

Nessa apresentação:

O código fonte desse componente se encontra disponível no repositório do projeto assim como o fonte do exemplo.

O componente depende do componente CorujaTree que é uma classe para facilitar a manipulação de XMLs mas, com um pouco de esforço pode ser adaptado para funcionar de modo independente.

Ferramentas para BPMN

2010-01-28T17:55:00.000-08:00

Recentemente estive procurando ferramentas gratuitas para criação de diagramas BPMN. Resolvi fazer este post para listar as melhores opções encontradas:

BizAgi

Pontos Fortes

Ferramenta completa para a geração de BPMN 1.0;
Licença sem restrição de uso comercial;
Exportação em imagem de alta qualidade;
Exportação para PDF, sharepoint, wiki, etc.;
Ferramenta de fácil uso;
Consideravelmente Estável.

Pontos Fracos

Roda apenas no sistema Windows;
Não apresenta histórico de alterações;
Não permite a geração de BPMN 1.1 ou BPMN 2.0;
Não exporta para imagem vetorial SVG;

Recomendação

Para ambientes de trabalho onde todos trabalhem com máquinas Windows, essa provavelmente é uma das melhores opções gratuitas.
O controle das alterações faz falta. Mas já aviso, fará falta na maioria das ferramentas aqui descritas, logo não é uma característica exclusiva.

BillFish Community Edition

Pontos Fortes

Fácil de instalar;
Roda em Windows XP, Windows Vista, Linux e Apple Mac;
Acesso remoto via Web;
Gera uma documentação PDF baseada no diagrama;
Permite a execução do fluxo como uma aplicação, que tenha até 3 usuários, caso este seja descrito conforme o recomendado pela ferramenta;
Permite a alimentação de informações de entidades, execução de decisões baseadas em informações, execução de eventos de interação e de eventos de tempo;
Sub-Processos.

Pontos Fracos

Não apresenta histórico das edições do BPMN;
Apresenta muitas instabilidades;
A exportação da imagem de saída é de baixa qualidade;
Não exporta para imagem vetorial;
Não é de tão fácil uso.
Não permite edição remota pela aplicação web disponibilizada;

Recomendação

Para quem deseja fazer uso dessas ferramentas que, teoricamente, dispensam a programação, essa pode ser uma boa solução.
Poder executar o fluxo em discussão na frente do cliente, sempre é um ponto positivo, mas o custo para poder usufruir tal funcionalidade é discutível.
Para poder utilizar essa ferramenta na sua equipe é necessário que todos que venham a necessitar ver o diagrama tenham ela instalada, pois a imagem resultante de um diagrama de tamanho médio já fica ilegível.
Alguns bugs na manipulação do zoom e das fontes, que foram observados na execução num ambiente linux, são realmente incômodos. Quando a ferramenta fecha sem aviso e sem salvar no meio da edição é desanimador.

Intalio|Designer Community Edition

Pontos Fortes

Muito facil de instalar. Na verdade, nem precisa instalar;
Roda no ambiente Eclipse logo em Windows, Linux, Apple e qualquer outra coisa que rode Eclipse;
Apresenta mapeamento de dados;
Edição de formulários integrados ao processo por WSIWYG;
Excelente integração com SOA, Schemas, LDAP, dentre outros ;
Geração de WSDL;
Exportação de Imagens em boa qualidade para PDF, PNG , JPEG, GIF e SVG;
Suporte a Reutilização de Processo;
Suporte a Tratamento de Exceções;
Ferramenta de facil uso;
Muita documentação;
Formato dos arquivos é de facil exportação para outras ferramentas;
Suporte a BPMN 1.1;
Apresenta histórico de alterações;
Validações automáticas geram alertas para possíveis erros.

Pontos Fracos

A manipulação dos conectores é limitada;
Não gera documentação além do próprio diagrama;
Não ter uma opção de execução assistida, sendo as saídas das decisões e eventos escolhidos dentre os disponíveis;
O histórico é restrito por execução ou pelo controle de versão, sendo a comparação no xml fonte do diagrama e não visual.
Não permite edição colaborativa;
Não permite edição remota pela aplicação web disponibilizada;

Recomendação

A ferramenta apresenta uma extensa gama de opções para quem desejar fazer uso de desenvolvimento sem código, geração automática de código BPEL, etc.
Para quem deseja apenas uma ferramenta de geração de diagramas ela atende muito bem. Como exporta em SVG, pode-se gerar a imagem no formato e na resolução que se desejar. Mas a imagem na resolução
padrão em GIF e JPEG poderiam ter as dimensões configuráveis.
A limitação da manipulação dos conectores incomoda, mas é superável.
A falta do controle de versão integrado ao diagrama em forma de histórico é grande, mas é compartilhada entre todas as ferramentas encontradas.
Os alertas da validação automática são muito úteis.

Conclusão

Dentre as ferramentas encontradas, a que melhor atendeu a minha necessidade foi a Intalio|Designer Community Edition, a qual tenho utilizado para a geração dos meus diagramas BPMN. Os fatores decisivos foram a facilidade de instalação, a exportação em SVG e a execução em várias plataformas.

Um final de semana conturbado

2009-09-15T13:39:00.000-07:00

Era uma semana puxada conforme o esperado, faltando menos de 100 dias para o casamento e com muita coisa para resolver, passando raiva com um Web Service no trabalho, botando contas em dia, etc. Eu passo essa semana com uma leve dor de garganta, mas aliviado. O Web Service funcionou perfeitamente. Finalmente eu havia encerrado os últimos detalhes do emprego anterior, incluindo é claro o plano de saúde. Estava então, numa pequena janela sem plano de saúde pois estava negociando no plano novo. Havíamos achado a viajem que queríamos e agora era fechar negocio. Detalhes, tudo se resolveria em uma semana. Pensava eu.

Numa sexta-feira essa leve dor se agrava um pouco e ir de encontro ao vento durante o almoço foi realmente doloroso. A noite enquanto ia buscar a minha noiva comecei a ter tontura e ficar realmente ruim. Ao encontra-la passei o carro para ela e já cancelamos toda a programação da noite.

Após custarmos a decidir se ela deveria ir me deixar em casa e voltar de táxi ou eu deveria deixa-la em casa e ir para a casa dirigindo, decidimos que era melhor eu deixa-la por que a casa dela era logo ali e eu aquentava ir para a casa. No caminho encontro uma barreira do detran aonde eu descubro que minha carteira esta vencida 2 dias além do limite permitido. Então eu, piorando, tenho que ligar para um motorista habilitado para não ter meu carro levado ao deposito.

Então, eu consigo ligar para minha noiva que vem com a sua irmã muito prestativa me buscar. Agora eu estava doente, sem plano de saúde, com uma multa e proibido de dirigir meu próprio carro. Devo confessar, fiquei um pouco desanimado.

Os próximos dias foram típicos de um doente. Hoje, terça-feira, já comecei a me sentir bem, tanto que até resolvi fazer esse resumo para os meus preocupados amigos. Ainda mais porque eu não estava atendendo muito o telefone o que deixou alguns ainda mais preocupados.

Hoje eu estou já bem melhor, uns 5kgs mais magro, naquela fase da doença onde se tosse muito, não sente fome mas ainda assim se sente bem melhor.

Achei na minha mãe, como sempre, uma pessoa em quem confiar nas horas difíceis. Minha noiva me viu fedido, doente, com o nariz escorrendo e de mal humor. Agora ela não pode reclamar de ter sido enganada. Além disso foi muito companheira e compreensiva em toda a situação, o que me fez gostar ainda mais dela. Ela até fez um macarrão! Percebi ter muitos amigos e até meu chefe foi mais compreensível do que eu estava acostumado. Fiquei 4 dias sem tocar num computador ( um recorde ! ) e consegui perder a pança que sairia nas fotos do casamento.

Por hora é só. Estarei voltando ao meu repouso e não devo ficar on-line muito tempo. Mas estou bem, cada dia melhor e cada dia mais satisfeito com as pessoas que estão ao meu redor. A todos, obrigado pelo carinho.

Dicas

2009-08-14T20:52:00.000-07:00

Alguns alunos meus e amigos me perguntaram em diferentes momentos o que eu recomendaria como primeiros passos para quem está começando no mundo do desenvolvimento. Então aqui vão algumas dicas:

Convenção de Código

Sempre que eu lido com o código, eu fico impressionado com a criatividade de programadores em codificar. Infelizmente, essa criatividade é utilizada de maneira a complicar algo simples, o que virá a dificultar a manutenibilidade do projeto. Quando se está aprendendo a programar, é comum se desenvolver de maneira desleixada se preocupando apenas com o resultado da execução. Essa prática deve ser evitada o quanto antes e uma das melhores maneiras de se fazer isso é se adotando uma convenção de código.

Não se espante ao discordar de algo da convenção. Praticamente todas as pessoas discordam da convenção em um ou mais itens, mas, ainda assim, é importante se aplicar a convenção combinada do começo ao fim do projeto. Num próximo projeto , caso toda a equipe fique de acordo, pode-se aperfeiçoar a convenção para o seu contexto, baseando-se também nas próprias lições aprendidas dos projetos passados.

Recomendo se começar com alguma convenção madura como a da Zend ou da Sun.

Controle de Versão

Hoje em dia, é praticamente impossível se trabalhar com programação sem se utilizar uma ferramenta de controle de versão. A qualidade das informações que esse tipo de ferramenta traz para o controle das alterações e versões do seu sistema torna-se imprecindivel quando se começa a desenvolver projetos grandes, seja em equipe ou não.

Vantagens:

Controlar "o que", "quando", "por quem" e "por que" de cada alteração feita.
Comparar versões do sistema.
Voltar a uma versão do sistema.
Combinar alterações.
Ver o histórico de um arquivo ou pasta.
Interface com várias aplicações que montam diferentes tipos de relatórios a partir dos dados do servidor.
Interface com várias aplicações possibilitando o disparo de testes automáticos, criação / alteração de demandas via mensagens de envio.

Dentre os mais famosos do momento temos o Subversion e o Mercurial.

Documentação automática

Documentar todos os métodos, classes e pacotes para possibilitar uma melhor manutenção é requisito mínimo para um bom projeto. Quando se documenta utilizando algum padrão de de documentação estilo javadoc, algumas ferramentas, entre elas o doxygen, possibilita a saída de relatórios muito ricos a partir da documentação criada. Um exemplo disto pode ser visto aqui, onde a documentação do projeto foi criada automaticamente a partir dos comentários existentes.

Teste Unitário

Apesar de ser algo essencial para a criação de softwares de qualidade, os testes unitários ainda são difíceis de serem encontrados em aplicações comerciais. Esses testes automáticos, também conhecidos como teste de fumaça quando aplicados a contextos pequenos, são similares aos casos de teste só que feitos automaticamente desde de contextos pequenos, como pequenos métodos que alteram uma string, até em contextos complexos, onde se pode testar todo um fluxo de funcionalidades, trabalhando em conjunto, num projeto.

Ao escrever esses testes automáticos existem ferramentas que podem executa todos eles em seu sistema, informar quais testes falharam, quais classes, métodos e linhas não foram executados, o que lhe informa que ou faltam testes no seu sistema ou existe código excedente.

Essas validações automáticas podem ser feitas a cada atualização do seu controle de versão, o que possibilita se saber de novos erros existentes no sistema assim que eles surgem, tornando seu sistema mais confiável e a manutenção facilitada.

As ferramentas mais conhecidas de teste unitário sao o JUnit e o PHPUnit e um exemplo de saída do PHPUnit pode ser vista aqui.

Padrões da Web

Conhecer os padrões da W3C deveria ser o ponto de partida de qualquer programador web. Infelizmente, isso não é nem de longe a regra. Eu, quando dou aula de programação, sempre me dedico a falar sobre o que é um XML, Schema e DTD, ensino os meus alunos a desenvolverem XHTML e falo um pouco sobre as validações da W3C. Para auxiliar no aperfeiçoamento das suas páginas desenvolvidas eu recomendo mais um plugin do firefox chamado Web Developer além do Relaxed e o Html Validator que infelizmente ainda não funciona no linux.

Para quem está realmente começando, um dos melhores sites em português é o Tableless.com.br. O w3schools é outra excelente referencia em relação ao assunto.

Prototipagem

Prototipo, WireFrame, Rascunho de Tela, etc. Todos esses nomes são para desenhos das telas que devem guiar os designers na criação do desenho final da tela. Esse rascunho será comparado com o fluxo de teste planejado e deve ser apresentado ao cliente antes de se iniciar a construção real do sistema. É natural que, com o desenvolvimento do sistema, alterações sejam feitas nas telas. Mas, ainda assim, o protótipo auxilia muito a reduzir a quantidade futura de alterações já dando um ponto de partida confiável para o desenvolvimento do sistema.

Algumas empresas fazem protótipo de tela em ferramentas não especializadas como powerpoint ou até mesmo no photoshop ou gimp mas existem muitas ferramentas feitas especialmente com este propósito. Dentre as gratuitas, a que eu mais recomendo é o Pencil Project, um plugin para firefox muito bom para prototipagem.

Modelagem de banco

Saber modelar bem um banco de dados e compreender um modelo é essencial para um bom sistema. Ao meu ver, a ferramenta gratuita mais popular é o DBDesigner4, mas, eu não a considero a melhor opção. Algumas outras opções, ainda gratuitas, que eu recomendo são o JDeveloper e o Power Architect.

Mas, é essencial estudar como fazer uma boa modelagem de banco de dados, não se restrigindo apenas às ferramentas. É importante estudar como deve ser uma boa modelagem de banco de dados, e existem muitos bons livros gratuitos para leitura como o Data Modeling Fundamentals

Modelagem de Processos de Negócio - BPM

Uma das ( muitas ) maneiras de se modelar um processo antes de implementa-lo é pelo bpm. Uma representação gráfica do negócio a ser implementado utilizando uma notação padrão. Quanto a ferramentas gratuitas para geração de bpms, recomendo o BizAgi apesar de não funciona no linux ( sem wine ou vbox ). Estou testando recentemente algumas aplicações novas, dentre elas o BonitaSoft, mas, ainda estou as estudando.

UML

Muito se fala de UML e existem muitos livros sobre o assunto, principalmente os livros de Engenharia de Software como o Sommerville. Não querendo entrar na discussão ideológica do assunto, um bom programador precisa conhecer os diagramas UML.

Dentre as ferramentas para criação de diagramas UML gratuitas e que rodam tanto no linux quando no windows, a que, até o momento, tem me mostrado os melhores resultados é o JDeveloper. Ferramenta muito boa para geração dos casos de uso, diagramas de classes, com sincronia codigo x diagrama, diagrama de negócio ( uma versão do UML do BPM ), etc. Não é, obviamente, o visual paradigm, mas, dentre as restrições apresentadas, me tem sido muito útil.

O diagrama no JDeveloper que para mim mostrou as maiores limitações foi o de sequencia. Mesmo após se informar que um "LifeTime" é um objeto de uma classe já existente ele não procura pelos métodos, trava as vezes sem nenhum motivo aparente, etc. Mas, como os projetos que eu tenho trabalhado recentemente são todos PHP, eu peguei o rascunho de código Java gerado pelo JDeveloper, converti em classes PHP e usei o CodeToDiagram conseguindo resultados muito legais.

Tenho também analisado outras opções como o Jude e StarUml mas confesso com pouca dedicação pela falta de tempo. Caso alguma dessas ferramentas venha a me encantar, farei um post novo a respeito.

Espero que essa descrição geral possa vir a ajudar a todos. Criticas e sujestões fiquem a vontade. Um grande abraço.

Reflections Entendidas e Estendidas

2009-05-20T21:19:00.000-07:00

PHP Reflections são recursos muito interessante que se você ainda não conhece precisa conhecer agora. O princípio é basicamente o seguinte: Você pode executar métodos que lhe trazem detalhamento sobre o funcionamento de arquivos / classes / funções que existam no seu código em execução.


/**
* Apenas um pequeno exemplo
*/

class exemplo
{}

$objReflection = new ReflectionClass( $strClass );
print $objReflection->getClassName();
print $objReflection->getDocComment();

Utilizando reflections é possível, por exemplo, se listar os parametros de um método ou função, podendo obter o nome, tipo e valor padrão, se houver, se cada um deles. Esses recursos podem ser extremamente úteis para possibilitar um debuger melhor, como se pode ver na ferramenta de backtrace do Renan de Lima.

Mas, as vezes, para poder se fazer funcionalidades realmente avançadas pode-se precisar d estender a classe das notações. Isso pode se tornar algo um tanto trabalhoso de se fazer tendo em vista as referencias cruzadas.

Por exemplo:

class teste{
}

class novaReflection extends ReflectionClass{}
$objNovo = new novaReflection( "teste" );

if ( $objNovo->getMethod( 'vai' )->getDeclaringClass() instanceofnovaReflection )
{
    print "bem que você gostaria.";
}
else

{ print "problema dificil de resolver"; }

Ao se tentar pegar a classe de reflexão da classe que contém o método ‘vai’ o php não retornou a classe estendida ‘novaReflection’ mas a classe ReflectionClass original. A referencia Elemento->getFilho()->getPai() falha não retornando um objeto da mesma classe do Elemento.

Essa situação problema se replica em todas as classes do Reflection. E, na idéia de se facilitar a criação de estensões para classes de reflection eu lhes ofereço o pacote de ExtendedReflection. Esse pacote de classes são estensões das classes do Reflection, mas com métodos chaves que, ao serem sobrepostos tornam fácil o processo de criação de estensões das classes dos reflections.

Ficou confuso? Então vamos a um exemplo:
Ao invés de se estender diretamente a classe do ReflectionClass você irá estender a classe ExtendedReflectionClass e deverá sobrescrever os seguintes métodos:

createExtendedReflectionClass
createExtendedReflectionProperty
createExtendedReflectionMethod

Estes métodos servem para converter um objeto do pacote Reflection nativo em uma objeto do pacote estendido de Reflection, tornando os links internos válidos.

Um pacote estendido para demonstrar isso é o Code Reflection que estende o pacote ExtendedReflection adicionando métodos novos nas classes de reflection o que torna possível se obter os códigos php dos objetos refletidos.

note em especial os seguintes métodos:


/**
* Make the recursive calls and indirectly call return the extended reflection object and not
* a native reflection property.
*
* @see ExtendedReflectionClass::createExtendedReflectionProperty( ReflectionProperty )
* @param ReflectionProperty $objOriginalReflectionClass
* @return CodeReflectionProperty
*/
protecte function createExtendedReflectionProperty ( ReflectionProperty $objOriginalReflectionProperty )
{
return new CodeReflectionProperty( $this->getName() , $objOriginalReflectionProperty->getName() );
}

/**
* Make the recursive calls and indirectly call return the extended reflection object and not
* a native reflection method.
*
* @see ExtendedReflectionClass::createExtendedReflectionMethod( ReflectionMethod )
* @param ReflectionMethod $objOriginalReflectionClass
* @return CodeReflectionMethod
*/
protected function   createExtendedReflectionMethod ( ReflectionMethod $objOriginalReflectionMethod )
{
return new CodeReflectionMethod ( $this->getName() , $objOriginalReflectionMethod->getName() );
}

Todas as referencias a objetos do pacote do reflection externos passaram antes, necessariamente, por esses métodos, que convertem o objeto reflection nativo no objeto reflection estendido.

Deste modo você tem a flexibilidade de estender uma classe com a riqueza dos recursos de uma classe de reflexão sem complicação, podendo gerar produtos bem legais como estamos fazendo no CodeToDiagram

Code To Diagram

2009-04-07T12:10:00.000-07:00

Gerando Diagramas de Sequência a Partir de Uma Execução PHP

Conforme prometido, após muito trabalho, estou publicando de fato o projeto CodeToDiagram de geração de diagramas. Para prover esse projeto estou utilizando o www.assem bla.com um site para administração de projetos muito legal. A ideia desse projeto é possibilitar a geração de diagramas de sequência a partir de execuções de código PHP. A descrição no site do projeto está em inglês. Mas aqui eu mando uma introdução a respeito do mesmo em português.

O diagrama de sequência talvez seja a mais intuitiva maneira de se compreender uma execução.

O seu uso na fase de pré-projeto é bastante comum para descrever o funcionamento esperado de um software. A partir dele podem-se desenvolver diagramas de teste, como também conferir se todas as funcionalidades descritas foram detalhadas em demais fases do planejamento tal qual o caso de uso, por exemplo.

Ao se descrever funcionalidades mais próximas das linhas de código, tal qual a interação de objetos através de métodos, se consegue planejar como serão as classes e as interfaces do sistema. Mas, a medida que o desenvolvimento avança, seja por falhas na análise ou por uma mudança nos requisitos, os diagramas vão se distanciando da realidade, perdendo o caráter descritivo e ganhando uma característica de legado.

Além disto, se solicitar a um analista que exista um diagrama de sequência de todos os testes do projeto seria um gasto enorme de tempo tanto na criação quanto na manutenção desses diagramas, tendo em vista que a mudança do nome de um método ou de um atributo num método alteraria todos os diagramas que envolvem este elemento.

A solução aqui proposta e implementada é a geração de diagramas de seqüência a partir de execuções de código PHP. Uma execução ou o trecho da execução é monitorado por classes de instrumentação de código que geram a partir das informações recebidas um diagrama daquela execução. Esse diagrama pode ser visto como HTML, salvo como HTML e em breve salvo como XML e futuramente exportado como imagem JPEG.

Todo este processo deve ser simples o suficiente para ser utilizado bastando uma simples chamada, mas também flexível para atender a todos os casos especiais. A idéia é gerar o diagrama de uma execução interferindo o mínimo possível no código-fonte o qual ela irá executar.

Em poucas palavras:

Este código:

<?php

require_once( '../../public/codetodiagram.php' ); CodeToDiagram::getInstance()->start(); require_once( 'Wolf.class.php' ); require_once( 'Pig.class.php' ); require_once( 'House.class.php' ); require_once( 'History.class.php' ); new History(); ?>

Resulta nesse diagrama

Um componente menor que foi gerado no processo da geração desta solução mas que pode ser utilizado individualmente é o gerador de diagramas de sequência a partir de um XML. Esta aplicação pode ser testada aqui onde um XML de exemplo já foi informado mas pode ser alterado a vontade.

A meta desta aplicação é a geração de um diagrama de sequência para cada método das classes de teste sendo cada um destes diagramas salvo com um nome de fácil localização. Algumas futuras funcionalidades devem ser acrescidas como mostrar a linha de código das chamadas, melhorar a explanação dos parâmetros, dentre outras.

Se você quiser utilizar esta solução em sua última versão, basta baixar do nosso SVN. Mas para apenas navegar no código ele é melhor legível aqui. Para testar a aplicação em funcionamento nos exemplos disponíveis clique aqui

Por hora o projeto ainda não funciona completamente no Internet Explorer. Mas ainda assim, o gerador já torna a vida mais simples na manutenção desse tipo de diagramas. Nós agradeceremos a qualquer um que tiver a paciencia e o desejo de fazer as mudanças no CSS necessárias para fazer o sistema funcionar no Internet Explorer.

Lembrando ainda, que a aplicação completa da UML 2.0 ainda está em desenvolvimento. Qualquer um que tiver interesse em trabalhar nesse campo é bem vindo ao time. Se você tiver uma correção ou uma extensão ao projeto que deseje nos enviar, será também muito bem recebida. E lembre-se, este é um software livre, e como tal, não dispõe de nenhuma garantia. Use por sua conta e risco. Ainda sendo um projeto em desenvolvimento sem nenhuma versão estável, erros podem ser encontrados. Caso os encontre por favor nos avise, teremos muito prazer em corrigi-los assim que possível.

Clique aqui para saber como utilizar essa solução.

Clique aqui para saber mais sobre diagramas de sequência.

Clique aqui e aqui para saber mais sobre Instrumentação de Código.

Clique aqui para conhecer a equipe de desenvolvimento responsável por este produto.

Gerador de Diagramas de Seqüência a partir de XMLs

2009-02-17T11:30:00.000-08:00

Recentemente, precisei gerar diagramas de seqüência automaticamente. Comecei a procurar geradores de diagramas de seqüência e de fato eu encontrei várias ferramentas que geram diagramas a partir de XMI. Dentre elas algumas que valem a pena serem citadas são: a Xmi2Svg e o Net Beans Uml Diagrams . O problema de todas as soluções apresentadas é que as entradas eram em XMI e, o pior um XMI extremamente específico, problema comum no XMI, o que o faz sair do próprio propósito original. O código do XMI é muito esquisito, na falta de uma palavra melhor. Um trecho de um diagrama de seqüência simples do Net Beans pode ajudar a demonstrar o que eu quero dizer:

</UML:GraphEdge.waypoints>
<UML:GraphElement.semanticModel>
<UML:Uml2SemanticModelBridge presentation="Message" xmi.id="xmi_id">
<UML:Uml2SemanticModelBridge.element>
<UML:Message xmi.idref="DCE.1F882CFB-E059-6341-7A50-2D9D63879AEB"/>
</UML:Uml2SemanticModelBridge.element>

Após muito procurar, eu resolvi partir para a filosofia "faça você mesmo". Então, após alguns dias de esforço, eu apresento a vocês o meu Gerador de Diagramas de Seqüência . Como é um código PHP, este está num link externo do meu ainda inutilizado dominio pessoal.

Neste conversor o XML de entrada é muito mais simples que o XMI, focado apenas no diagrama de seqüência , sendo facilmente compreensível. Conforme exemplo:

<sequence>
<actors>
<actor id="1" type="user">me:people</actor>
<actor id="2" type="system">you:people</actor>
</actors>
<messages>
<message type="call" from="1" to="2" text="hi"/>
<message type="return" from="2" to="1" text="hello"/>
</messages>
</sequence>

Gere então seu próprio XML, divirta-se no exemplo dos "Três Porquinhos" e me diga o que achou. Esse gerador de diagramas faz parte de um plano muito maior que eu ainda não revelarei para os senhores. Mas saibam que no fim tudo será revelado!!!

Métodos Mágicos no Javascript.

2009-01-12T14:28:00.000-08:00

Uma das coisas que eu mais gosto em php é a simplicidade junto com a riqueza de recursos. Um recurso muito conhecido, de uso simples mas que é extremamente interessante são os métodos mágicos. Uma vez eu estava me perguntando se existiria algo parecido com isto em javascript e a resposta é: "depende". Na verdade esse recurso está disponível no firefox e foi nele que eu achei a documentação a respeito.

O equivalente ao __call é o __noSuchMethod__
O equivalente ao __set é o __lookupSetter__
O equivalente ao __get é o __lookupGetter__

Tudo isso e muito mais pode ser visto neste link do site da Mozilla Firefox.

Não sei se ele chega a funcionar no Safari ou no Google Chrome, eu particularmente duvido devido ao fato de não ser padrão, mas CERTAMENTE não funciona no Internet Explorer.

Ainda assim, quando se deseja depurar páginas javascript no Firefox, fazer esses métodos gerarem uma exceção já ajuda bastante a se encontrar o erro, pode-se ainda fazer as "classes" de seu framework todas extenderem de uma classe padrão que ao se tentar ler ou escrever qualquer atributo inexistente ou chamar um método inexistente gere uma exceção evitando, principalmente ao lidar com atributos, que valores "undefined" possam ser lidos ou que novos atributos "fantasmas" possam aparecer nos seus objetos.

Infelizmente não podemos utilizar isso como recurso de framework tendo em vista a restrição de uso, salvo alguem tenha alguma ideia genial para fazer isso funcionar em qualquer navegador. Não vale citar o projeto Tamarin!! Alguma idéia ?

Head Tracking - Web 3D

2008-09-27T09:57:00.000-07:00

Maioria de nós, já vimos em ficções científicas como no futuro a internet seria 3D. Muito barulho foi feito de como isso poderia ser fantástico, mas o "como fazer", "de que forma", "a que custo" e talvez até o mais importante, "como isso pode ser útil" sempre são questões que apenas a realidade responde.

Nesse video, Jonnhy Chung Lee fala a respeito de como isso pode ser feito com um monitor normal, se alterando a imagem apresentada, ainda em 2D, através de uma projeção a partir do ponto de vista do observador. Para se rastrear a posição do observador, ele utilizou o contole do Nitendo Wii.

Apesar do resultado já impressionante, este método ainda exige que o usuário do seu site tenha um Nitendo Wii. Bem, Chris Harrison em seu projeto de Head Tracking, numa tradução livre "Monitoramento de Face", utiliza a web cam para detectar aonde está o observador e faz a mesma triangulação sem necessitar do Nitendo Wii.

Por último, falta "apenas" colocar isto tudo num flash. Aparentemente, no que depender de Jim Foley, não vai demorar tanto. Ele já está rascunhando um flash que faz este processo usando o infra vermelho.

Muito mais nesta área está para vir. Como podemos ver em http://wiiflash.org/ os desenvolvedores e designers estão a todo vapor, em breve estaremos vendo várias páginas com contéudo 3D. Além disto, o Head tracking, pode ser utilizado para várias outras aplicações, como podemos ver em outro projeto do Chris Harrison

Formei!

2008-09-27T09:26:00.000-07:00

Gostaria de agradecer a todos aqueles que de alguma forma contribuíram para isto.

Um agradecimento especial ao meu grande amigo Renê de Lima , que foi meu companheiro de curso, de trabalho, de sinuca, e parceiro na nossa monografia, a professora Cláudia Nalon, a qual eu tenho muito orgulho de ter sido aluno, e a toda a minha família é claro.

Muitos projetos pessoais que estavam na gaveta ou em marcha lenta estão aos poucos, saindo do papel.

Em breve muitas novidades.

Ok. Vocês venceram

2008-05-28T18:00:00.000-07:00

Olá todos. Meu nome é Thiago da Mata ou na versão longa Thiago Henrique Ramos da Mata.

Eu tenho, ou talvez devesse dizer tinha, um blog no thiagomata.blog.com. De fato um endereço facil de se achar.

Eu não sou o tipo de pessoa mais exigente com recursos, mas o blog.com, mesmo para alguem pouco exigente como eu, apresentou vários problemas que me fizeram decidir mudar de endereço e tudo mais.

O maior motivo foi a incapacidade de lidar com vários acessos simultaneos, várias pessoas reclamaram de que não conseguiam acessar o blog, que ele ficava fora do ar, demorava muito, etc.

Acredito que neste blog do google não vou ter esse tipo de problema.

Caso você não me conhecia antes, eu sou um desenvolvedor, prioritariamente web, gosto de acompanhar as novidades de recursos no mercado, principalmente os gratuitos.

Bastante curioso em várias areas do desenvolvimento, o meu forte até o presente momento é o desenvolvimento em PHP e o Javascript.

Estou desenvolvendo um framework PHP com alguns amigos que está bastante interessante. Mas ainda faltam alguns detalhes de desenvolvimento e principalmente de documentação para ser publicado.

O rítmo está meio lento devido a minha provável e possível e inacreditável tão esperada formatura na UnB sendo o final de uma saga de vários e vários e vários anos.

Não sou do tipo que escreve muito mas vou utilizar este recurso como uma maneira de me comunicar como de guardar algumas coisas que eu considero interessante. Não pretendo falar estritamente de desenvolvimento apesar de até o momento todos os posts que eu enviei ( no blog anterior ) são relacionados a area.

Abraços e até mais,
Thiago Mata.