Os 10 (dez) maus
hábitos dos
desenvolvedores JSF
Rafael Ponte
http://www.rponte.com.br
rponte@gmail.com

Quem?
“Rafael Ponte”
● Desenvolvedor
● Coordenador do grupo JavaSF
● Entusiasta Java e JSF
● Sócio da Triadworks
● Trabalha na IVIA

JSF tenta encapsular
toda a complexidade no
desenvolvimento web
com Java

A maioria dos desenvolvedores webs que
já trabalharam ou trabalham com algum
framework “action-like” acabam tendo
grandes dificuldades ao desenvolverem
com JSF.

Criando-se então maus
hábitos..

10º Mau hábito

Usar <c:if/> ou <c:when/>
para esconder componentes
do usuário

<c:if test=”#{bean.admin}”>
<h:dataTable var=”row”>
<h:column>
...
</h:column>
</h:dataTable>
</c:if>

Usar <c:if/> ou <c:when/>
SOLUÇÃO?
para esconder componentes
do usuário

Utilizar o atributo
rendered dos
componentes para
escondê-los do usuário

<c:if test=”#{bean.admin}”>
<h:dataTable
rendered=”#{bean.admin}”>
<h:column>
...
</h:column>
</h:dataTable>
</c:if>

9º Mau hábito

Usar rendered=quot;#{bean.alive}quot; em
um componente que dispare
eventos quando quot;beanquot; é de
escopo de request

<h:commandButton value=”Salvar”
action=”#{bean.salvar}”
rendered=”#{bean.admin}” />

Usar rendered=quot;#{bean.alive}quot; em
um componente que dispare
eventos SOLUÇÃO?
quando quot;beanquot; é de
escopo de request e quot;alivequot; é um
atributo boolean de classe.

Ampliar o escopo do
managed bean para session
ou se utilizar de algum
framework ou componente
de escopo conversacional

O uso indevido ou exarcebado da
session é prejudicial para a
aplicação.

mais longo que request | mais curto que session
✔
Myfaces Tomahawk [t:saveState]
✔
Myfaces Orchestra
✔
Myfaces Trinidad [pageFlowScope]
✔
JBoss Seam
✔
JBoss Richfaces [a4j:keepAlive]
✔
etc

8º Mau hábito

Acham que a tag <redirect/>
nas regras de navegação
muda apenas a url da barra
de endereço do browser

SOLUÇÃO?

entendam
Simplesmente
como funciona um
REDIRECT

7º Mau hábito

Alterar o estado de algum
componente no lado cliente
[browser] através de javascript e
esperar que isso seja “entendido”
pelo JSF

Alterar o estado de algum
componente no lado cliente
[browser] SOLUÇÃO?
através de javascript e
esperar que isso seja “entendido”
pelo JSF

Alterar o estado do
componente no lado
servidor via AJAX e
re-renderizar o
componente

6º Mau hábito

Utilização demasiada de
parâmetros de request e
desenvolvimento voltado a quot;chave
primáriaquot;

Utilização demasiada de
parâmetros de request e
SOLUÇÃO? a quot;chave
desenvolvimento voltado
primáriaquot;

Pensar mais orientado a
objetos e deixar com que os
componentes troquem
entidades e não “chaves
primárias”

5º Mau hábito

Não implementam os métodos
equals() e hashCode() das
entidades da aplicação

Esquecem de implementar os
métodos SOLUÇÃO?
equals() e hashCode()
das entidades da aplicação

Apenas
implementem os
métodos

4º Mau hábito

Implementam o
próprio mecanismo de
SEGURANÇA

SOLUÇÃO?

Utilizem um framework
especializado

3º Mau hábito

Paginação de
registros na session

Uma das melhores maneiras de
matar a escalabilidade da
aplicação é a utilização
indiscriminada da session

SOLUÇÃO?

Paginação sob
demanda

2º Mau hábito

Utilizam os
componentes AJAX
de maneira
INEFICIENTE

SOLUÇÃO?

Regras de navegação
orientada a páginas
estados

1º Mau hábito

1º -e o pior- Mau hábito

JSF LIFECYCLE

JSF LIFECYCLE
A maioria dos
desenvolvedores NÃO
entendem

JSF LIFECYCLE
SOLUÇÃO?

http://balusc.blogspot.com
/2006/09/debug-jsf-lifecycle.html
Entendam o
ciclo de vida

Concluindo..

Perguntas?

Obrigado!
rponte@gmail.com
http://www.rponte.com.br