A falta de um (bom) suporte a estas linguagens no Eclipse me incentivou a buscar outras alternativas de IDEs para poder estudar e brincar um pouco com elas. Depois de algumas buscas no Google e experimentações, escolhi o NetBeans 6.5 como o ambiente mais recomendado para mim (não, este notebook não é um Mac para usar o TextMate, aqui é Ubuntu mesmo…).

Então, com a nova versão saída do forno devidamente instalada, começo a brincar com Ruby e Rails:  suporte nativo a JRuby, wizards, migrations, sccafolding, autocompletação, generators, testes, suporte a instalação de plugins para ruby e rails, tudo lá!!

Uma maravilha!! E com os atalhos configurados para ficarem iguais aos do Eclipse então…

Isso se não fosse um “pequeno” e chato pra caramba (pra não usar outra palavra que exprima com mais força a raiva que isso causa) bug do NetBeans: é comum o editor travar e o cursor fica lá sem você poder digitar nada…

Foi então que lembrei que foi por isso que deixei de usar uma versão beta há um tempo atrás: esse bug estava lá, e eu achava que era algum problema temporário na build que havia baixado. Não era!!

Pesquisando no Oráculo descobri que não era o único com este problema e que havia um bug aberto no Issue Tracker do NetBeans. E o pior: com status ABERTO e sem previsão de uma solução… E agora?? Adeus NetBeans de novo??

Comecei a ler os comentários do problema e nada… Até que entre as dezenas de posts achei uma solução prática: Rodar o NetBeans com o Java 7!!

Uma solução um tanto estranha a princípio, mas funciona: meus problemas se acabaram-se!!

Um passo-a-passo, por favor?

Abaixo estão os passos que fiz para me ver livre (até agora…) deste problema:

1. Baixe o snapshot mais recente da JDK7
2. Execute o instalador, que apenas descompacta os arquivos na sua máquina
3. Altere o arquivo de configurações do NetBeans (<caminho_do_netbeans>/etc/netbeans.conf), definindo o local da JDK que ele irá usar. Por exemplo, minha configuração ficou netbeans_jdkhome="/home/wendell/desenvolvimento/java/jdk1.7.0"
4. Execute o NetBeans!

Lembrando que não é necessário que seus projetos também passem a utilizar a JDK7 para serem compilados. Pode continuar normalmente também com a JDK6 na sua máquina…

(E eis que depois de um quase abandono, um suspiro de vida surge na Toca do Calango…)

Beginner jQuery Tutorials: http://webtecker.com/2008/06/02/beginner-jquery-tutorials/

Lá você encontrará uma coleção de links para tutoriais e fontes de informação (em inglês) para iniciar ou continuar seus estudos desta excelente biblioteca…

Divirta-se!!

E não custa lembrar que, além de linguagens, frameworks, IDEs e todo o resto, temos nessa área um outro importante personagem: o browser (ou navegador, se assim prefirirem). Ele pode ser ao mesmo tempo o vilão, ao forçar a caça a “recursos técnicos” para driblar bugs (não IE mesmo?), ou o mocinho, ao proporcionar mecanismos auxiliares para que o desenvolvedor tenha mais liberdade e poder para alcançar os resultados desejados. É preciso saber escolher… E para mim o Firefox tem sido uma ótima escolha!

Disponibilizando vários e interessantes plugins (ou complementos), este navegador é hoje o preferido da maioria dos programadores e geeks pelo mundo. E para quem necessita fazer manutenção em páginas web, o aclamado plugin Firebug (que em breve deverá receber um post mostrando suas funcionalidades) é praticamente obrigatório.

Mas além dos plugins, existem outras pequenas jóias personalizáveis que podem ser agregadas aos navegadores…

Os bookmarklets

Resumindo a estória, bookmarklets são pequenos trechos de código javascript que podem ser adicionados aos links favoritos e que proporcionam algum comportamento desejado para a página atual quando são executados. Geralmente estão disponíveis na Internet como links que podem ser arrastados diretamente para a barra de favoritos para que fiquem disponíveis sempre que necessários. Aproveito para avisar que alguns só funcionam no Firefox…

Dentre os que mantenho sempre à mão estão o CSS Reloader, que recarrega as folhas de estilo da página sem que seja necessário um refresh completo, e o Design, que auxilia na definição ou verificação de layouts.

E agora o motivo deste post… Apresento minha mais nova “aquisição”: o jQuerify.

Este bookmarklet possibilita disponibilizar em qualquer página o framework javascript jQuery, mesmo que ela não o importe inicialmente!!

Agora você pode perguntar: “Sim, e daí??”

E daí que o jQuery possibilita você manipular qualquer coisa em um documento HTML, e agora você tem todo esse poder em qualquer página que você precise! Executando o jQuerify e em seguida utilizando o console javascript disponível no Firebug, você tem inúmeras maneiras de modificar uma página que você esteja visitando.

Posso estar exagerando um pouco na minha empolgação, mas depois que você começa a usar o jQuery e percebe que o conhecimento sobre seletores CSS pode ser agregado a funções javascript com possibilidades infinitas (eita!!), quer ter isso sempre disponível… Mesmo que seja só para “ajustar” o site dos outros para ficar do jeito que você prefere…

Este framework de mapeamento objeto-relacional tornou-se o padrão de facto para realizar o gerenciamento de entidades persistentes em aplicações Java (depois do fiasco dos Entity Beans), tendo muitas de suas idéias adotadas na especificação da JPA. Além da facilidade de definição dos mapeamentos e de uma completa API para a realização de consultas, um dos seus pontos fortes é a ótima documentação disponível.

Entretanto, existem algumas funcionalidades para as quais esta documentação é quase inexistente. E dentre elas temos os esquecidos, mas bastante úteis, transformadores de resultados.

O problema!

Para entender a utilidade deste recurso, considere a seguinte consulta de alunos utilizando HQL (os detalhes podem ser abstraídos sem maiores problemas):

...
List resultado = session.createQuery("select matricula, nome, curso.nome from Aluno").list();
...

Com esta simples projeção restringimos a busca e aumentamos a performance da consulta de todos os alunos persistidos. Entretanto, teremos como resultado final uma lista de Object[] que precisaria ser manipulada para extrair os diversos campos.

Esta manipulação podería ser um laço para percorrer a lista resultante e, para cada array de objetos, instanciar DTOs ou entidades. Simples, mas nada divertido…

Ou então poderíamos criar um construtor para aluno que aceite os parâmetros da consulta e substituir a query por "select new Aluno(matricula, nome, curso.nome) from Aluno" . Dessa forma teríamos uma lista de alunos pronta, mas que necessitaria de novos construtores a cada novo parâmetro necessário.

Para resolver problemas deste tipo é que vamos em busca dos ResultTransformers.

A interface ResultTransformer

Escondida na API do Hibernate existe uma interface que possibilita transformar o resultado de uma consulta, seja ela com Criteria, HQL ou SQL (o suporte aos dois últimos foi adicionado na versão 3.2) que utilize projeções em uma representação mais prática do que, por exemplo, uma lista de Object[]. Apresento então a pequena ResultTransformer:

public interface ResultTransformer extends Serializable {
	public Object transformTuple(Object[] tuple, String[] aliases);
	public List transformList(List collection);
}

Os dois métodos especificados são aplicados em diferentes momentos para transformar o resultado de uma query: transformTuple é chamado durante o processamento inicial do resultado, com acesso às colunas retornadas pela consulta e aos aliases especificados para cada uma delas (se existirem); no caso de transformList a chamada é imediatamente antes do Hibernate retornar o resultado de uma consulta.

Alguns transformadores prontos para usar

Mas de que adianta uma interface sem implementações, não é? Felizmente o Hibernate disponibiliza algumas classes prontas para serem usadas em seus projetos.

Voltemos ao nosso problema: como não ter trabalho para manipular o resultado de consultas com projeção?

A primeira opção é o AliasToBeanResultTransformer. Este transformador mapeia aliases (se você não sabe que o são alias, aguarde mais um pouco para entender com o exemplo) de colunas em atributos de objetos pertencentes à classe definida em seu construtor, populando-os através de métodos setters (via setter injection). A utilização pode ser vista no exemplo abaixo:

...
List<AlunoDTO> alunos = session
    .createQuery( "select matricula as matricula, nome as nomeAluno, curso.nome as nomeCurso from Aluno" )
    .setResultTransformer(new AliasToBeanResultTransformer(AlunoDTO.class))
    .list();
...

Comparando com o código original vemos algumas diferenças. A primeira é a utilização da palavra-chave “as”. Esta é a forma de definir aliases (apelidos) para as colunas que serão utilizados para popular instâncias da classe AlunoDTO através de setters no estilo setNomeAluno() ou setNomeCurso().

A segunda diferença é a chamada ao método setResultTransformer() da interface Query. Com ela é possível determinar uma estratégia de transformação de resultados de acordo com a necessidade da consulta. Neste caso, informamos uma instância de AliasToBeanResultTransformer, definido para transformar as colunas em objetos do tipo AlunoDTO.

Como alternativa para a criação de DTOs ou de métodos setters em entidades podemos utilizar o AliasToEntityMapResultTransformer. Com ele a lista de tuplas será transformada em uma lista de mapas, onde cada cada um deles terá um conjunto de entradas alias => valor_da_coluna. Dessa forma temos uma representação mais fácil de ser manipulada do que a original.

Logo abaixo vê-se um exemplo de seu emprego:

...
List<Map<String,Object>> mapaAlunos= session
    .createQuery( "select matricula as matricula, nome as nomeAluno, curso.nome as nomeCurso from Aluno" )
    .setResultTransformer(new AliasToEntityMapResultTransformer())
    .list();
...

Viram como este recurso pode ser útil? Além destes dois apresentados existem mais transformadores que podem ser utilizados em outros casos, como o DistinctRootEntityResultTransformer, empregado para evitar duplicidade de entidades no resultado. E se ainda não for suficente, sempre é possível criar novas estratégias implementando a interface ResultTransformer.

Entretanto, é bom lembrar que, por trás de todas estas maravilhas da praticidade moderna que o RichFaces oferece, ainda temos o bom e velho JavaScript por baixo dos panos. É esta incrível linguagem, que somente recentemente começou a ganhar o prestígio merecido, que move a maioria das funcionalidades mágicas dos componentes. Para tal, os desenvolvedores da biblioteca utilizaram-se de dois frameworks JavaScript bastante conhecidos: Prototype e Script.aculo.us (baseado no primeiro).

Estes dois já foram (e alguns ainda os consideram) os preferidos para auxiliar no desenvolvimento de soluções em JavaScript. Por causa disso vários outros projetos incorporaram estas bibliotecas para agregar comportamentos diversos a por exemplo: componentes JSF. E adivinha quem também fez essa escolha? o pessoal do RichFaces…

Muito bem, mas e o jQuery? Onde ele entra nessa história toda?

Acontece que o jQuery e seus diversos plugins estão cada vez mais na cabeça (e nos códigos) dos desenvolvedores web. Ele vai além do Prototype em vários aspectos: ganhou inúmeros admiradores e contribuidores, e é hoje uma opção mais conveniente para a adição de comportamentos à paginas web.

Resumindo então o cenário: temos os componentes prontos do RichFaces que encapsulam transparentemente códigos que utilizam Prototype e Script.aculo.us e, caso necessário, podemos adicionar outros comportamentos necessários com jQuery.

Qual o problema então?

O “problema” é que um importante método tanto do Prototype quanto do jQuery possuem nomes iguais!

A principal função do Prototype, e que é utilizada basicamente para reduzir o tamanho dos códigos de manipulação de elementos da árvore DOM, é a $(). Esta pequena função substitui o longo método original para a busca de elementos da página por seu id: document.getElementById().

No jQuery, a função $() é o grande coringa: serve para buscar elementos da página através de seletores CSS, para criar novos elementos para serem adicionados à página ou para definir funções que devem ser executadas assim que a árvore de elementos tiver sido carregada pelo navegador (depois providencio um post mais detalhado sobre esta função tão versátil).

Então não é possível usar as duas ao mesmo tempo? E já que RichFaces utiliza Prototype, não posso usar jQuery quando empregar seus componentes? Mas é claro que pode!!

É possível utilizar as funcionalidades das duas bibliotecas com uma pequena adaptação: definindo um nome alternativo para a função $()do jQuery e utilizando-a sem a preocupação com conflitos com o Prototype. Veja o código abaixo como esta alternativa pode ser utilizada:

var $j = jQuery.noConflict();

$j("div").hide();
$('rodape').show();

Neste exemplo, a função $j() irá funcionar com o comportamento desejado para o jQuery e a função $() funciona como a sua definição original do Prototype. Simples assim!

Agora você pode usufruir do melhor dos dois mundos: a praticidade dos componentes prontos e a flexibilidade de definir novos comportamentos ou utilizar os plugins prontos do jQuery.

Acho que para um primeiro post “de verdade” este até que ficou bem longo… A idéia parecia bem simples no começo, mas a necessidade da contextualização acrescentou algumas linhas a mais…

E no caso de alguma dúvida, o espaço para comentários está aí para ser utilizado!

Depois de muito tempo do surgimento da idéia de manter um blog, finalmente a procrastinação teve seu lugar tomado pelo primeiro post. A simplicidade do WordPress (e sua gratuidade) facilitaram a concretização, em apenas alguns minutos, de um local para ruminar sobre assuntos pseudo-aleatórios relacionados ao desenvolvimento de software.

A idéia é proporcionar aos leitores discussões sobre novidades na área de desenvolvimento (que serão inicialmente mais ligadas a Java, Ruby e JavaScript), idéias para soluções de problemas (e às vezes os problemas em si…) ou qualquer coisa que eu ache interessante de ser compartilhada.

Este é apenas o passo inicial e espero conseguir manter a motivação e a inspiração para muitos outros posts…