Mr. JSF or: How I Learned to Start Worrying and Hate the Framework

Desde há cerca de 2 anos para cá, tenho trabalhado intensamente com Java Server Faces no desenvolvimento web em Java. Inicialmente as coisas não correram muito bem, pensou-se por a tecnologi

a ser ainda muito nova e ainda verde. Depois, continuaram a não correr bem. No futuro, espero que não corram.
Cheguei à conclusão que JSF não é a melhor solução para desenvolvimento web em Java e consegui reunir umas quantas razões minhas:

  • JSF é uma especificação

JSF é uma especificação e existem diversas implementações, sendo que a Sun fornece uma Reference Implementation. Por um lado, a especificação deixa pequenos detalhes de implementação à escolha dos implementadores e por outro, existem algumas falhas de desenho na especificação, assumidos inclusivamente por quem está a trabalhar na versão 2 do draft de especificação.

  • Fases

O processamento JSF é dividido em 6 fases e é definida a ordem e o que ocorre em cada uma delas. O programador, em muitas situações, tem de ter a noção de fase presente quando está a programar, a desenvolver as suas acções, etc. Requer um conhecimento que apenas é adquirido com experiência e muitas falhas Aliás, tanto a noção de fases como as questões de request e sessão também deveriam ser o mais transparentes possíveis para quem desenvolve, deixando o programador dedicar-se a desenhar o interface e adicionar comportamento aos elementos do interface, como se fosse uma simples aplicação.

  • Bugs

Historicamente, foram detectados alguns bugs graves nas implementações de JSF. Um dos exemplos é o do JSF gerar identificadores que já existiam declarados pelo utilizador na página, se foi resolvido passado meses.

  • Identificadores Únicos

Temos de ter cuidado com identificadores duplicados e acaba-se por ter de se definir o id de cada componente da página. Obtemos um erro quando tentamos consultar a página e a origem do mesmo é não raras vezes difícil de depurar.

  • Renderkit

Renderkits são um esquema falhado, no que toca a desenvolver para web. Em casos reais é quase impossível fazer output para múltiplos outputs sem alterar o conteúdo do jsf. Além disso, a geração de html está escondida dentro do renderkit e é difícil de controlar.

  • Web Semântica e Acessibilidade

É muito difícil controlar o código que é gerado pelo JSF .
No mundo actual, quer-se markup semanticamente correcto, separação entre informação semântica (XHTML) e apresentação gráfica (CSS) e acessibilidade para utilizadores com necessidades especiais. Deve ser possível ter um controlo fino sobre o markup gerado. As interacções com os designers (mesmo com o meu post anterior não nos safamos) tornam-se mais complexas pois o programador não consegue replicar o código criado pelo designer.

  • Manutenção de estado

Para manter o estado entre requests, o JSF fornece apenas a noção de sessão. Componentes como o SaveState do Tomahawk ou novas frameworks facilitadoras como o JBoss Seam permitem ter a noção de Conversation numa aplicação JSF. Se não forem utilizados estes componentes, o programador é obrigado

a usar a sessão, caindo no erro comum de definir Managed Beans como de sessão quando tal não é adequado. Ou então colocando a informação do bean em sessão e recuperando-a quando necessário, no caso de beans de sessão. Ao usarmos estes esquemas de sessão não conseguimos, por exemplo, navegar em duas páginas da mesma aplicação ao mesmo tempo.

  • ValueChangeListeners

Os eventos são processados mesmo quando não é esperado. Por exemplo, se tivermos uma dropdown com um ValueChangeListener e um valueBinding para uma nossa String, se submetermos a página sem alterar a dropdown, o evento será lançado porque o valor anterior da variável era null e o que é submetido é o valor default. Além disso, quando temos dropdowns com immediate=”true” e fazemos alterações no ValueChangeListeners, temos de saltar para fase de RenderResponse para que não tenhamos os dados reescritos. Duas palavras: mau desenho.

Estas são razões que chegue para não usar JSF. O que acontece em muitos casos, é usarem-se frameworks que tornem a tecnologia suportável, como sejam os componentes Tomahawk ou as frameworks Facelets e JBoss Seam.
Quando finalmente se chega à conclusão que existem outras frameworks que são melhores que JSF, encontramos coisas como o Tapestry ou o Wicket. Estas duas frameworks permitem-nos definir o interface com markup xhtml, conseguindo assim a desejada interacção com os designers e podendo, inclusivamente, fazer as nossas páginas directamente do protótipo.

CSS for dummies

Para a grande maioria dos programadores, java inclusive, css é um mistério obscuro. E coisa de designers. E de meninas.Mas na realidade, para quem trabalha para web, temos de saber xhtml e css pois nem sempre temos designers e protótipos e todas essa

s benesses.
Depois, quando tentamos fazer páginas todas bonitas, acessíveis, com separação de semântica da apresentação perdemos horas e horas e sentimo-nos parvos.

Hoje, consegui finalmente perceber o conceito de

float, graça a este excelente tutorial: CSS Float Theory: Things You Should Know.

Não deixem de ler este artigo, é muito muito bom.

Novo sítio para o blogue

Mudámos de sítio!
O JRoller foi o nosso primeiro local

de escrita, principalmente por ser uma comunidade direccionada a java, mas não gostámos. Falta de suporte, versões do buy viagra without prescription

g/”>Apache Roller que não eram actualizadas à séculos e dificuldade em ter templates decentes para o site.

Depois de muito e bem se ter ouvido falar do WordPress e tendo um hosting próprio mais ou menos inutilizado, decidiu-se colocar o blog em hosting próprio e com um domínio todo bonito. Agora somos pessoas da moda e temos um blog todo acessível, web 2.0 e bonito. Temos imagens de topo com tons campestres, o que certamente evoca a ideia que todos temos da Zona J :)

As novidades resumem-se então a:

  • Novo look, mais limpo e acessível;
  • Feeds ligadas ao FeedBurner, sendo que agora é possível saber-se quantos utilizadores lêem o nosso blog pela feed rss;
  • Tags – Cada post deixa de ter de pertencer apenas a uma categoria e passa a poder ser tagged;
  • Os excertos de código estão agora mais limpos e podem ser lidos tanto na página como no feed rss, pois utilizam o Google Code Prettify;
  • Uma pesquisa que realmente funciona;
  • Instalámos o JQuery e aconselha-se toda a gente a olhar para esta maravilha (segundo o Ricardo Antunes);
  • Comentários validados – a primeira vez que um utilizador insere um comentário, este tem de ser validado, por questões de spam. A partir do momento em que o comentário seja validado, todos os comentários desse utilizador serão automaticamente validados;

Claro que nem tudo podem ser rosas: Embora tenhamos migrado os posts do antigo blog, não foi possível migrar os comentários. Como tal, se alguém quiser ver os comentários terá sempre o blog antigo disponível para consulta.

Por enquanto é tudo, não se esqueçam de apontar os vossos leitores de RSS para o seguinte endereço:

http://www.zonaj.org/?feed=rss2