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

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

3.
JSF tenta encapsular
toda a complexidade no
desenvolvimento web
com Java

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

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

6.
10º Mau hábito

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

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

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

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

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

12.
9º Mau hábito

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

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

15.
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.

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

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

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

19.
8º Mau hábito

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

21.
SOLUÇÃO?

22.
entendam
Simplesmente
como funciona um
REDIRECT

23.
7º Mau hábito

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

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

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

27.
6º Mau hábito

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

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

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

31.
5º Mau hábito

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

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

34.
Apenas
implementem os
métodos

35.
4º Mau hábito

36.
Implementam o
próprio mecanismo de
SEGURANÇA

37.
SOLUÇÃO?

38.
Utilizem um framework
especializado

39.
3º Mau hábito

40.
Paginação de
registros na session

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

42.
SOLUÇÃO?

43.
Paginação sob
demanda

44.
2º Mau hábito

45.
Utilizam os
componentes AJAX
de maneira
INEFICIENTE

46.
SOLUÇÃO?

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

48.
1º Mau hábito

49.
1º -e o pior- Mau hábito

50.
JSF LIFECYCLE

51.
JSF LIFECYCLE
A maioria dos
desenvolvedores NÃO
entendem

52.
JSF LIFECYCLE
SOLUÇÃO?

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

54.
Concluindo..

55.
Perguntas?

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