Os 10 maus habitos dos desenvolvedores jsf (JustJava e CCT)

2,843 views
2,790 views

Published on

Toda tecnologia tende a trazer consigo um novo paradigma de como desenvolver partes específicas de software, contudo, algumas novas práticas nem sempre são entendidas, e algumas vezes antigas práticas permanecem dentro do novo paradigma tornando-se assim maus hábitos, e com JSF não seria diferente.

Aqui será apresentado 10 discussões sobre os maus hábitos mais comuns entre os desenvolvedores JSF, hábitos encontrados não somente entre iniciantes, mas também entre alguns desenvolvedores mais experientes, e por sua vez será apresentado soluções para cada um deles.

Published in: Technology
1 Comment
5 Likes
Statistics
Notes
No Downloads
Views
Total views
2,843
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
42
Comments
1
Likes
5
Embeds 0
No embeds

No notes for slide

Os 10 maus habitos dos desenvolvedores jsf (JustJava e CCT)

  1. 1. Os 10 (dez) maus hábitos dos desenvolvedores JSFRafael Ponte Tarso Bessahttp://www.rponte.com.br http://www.tarsobessa.comrponte@gmail.com tarso.bessa@gmail.com
  2. 2. Antes de mais nada, uma provocação gratuita
  3. 3. BRUNO PEREIRA01/01/1990 19/09/2009
  4. 4. RIP - REST in Peace BRUNO PEREIRA 01/01/1990 19/09/2009
  5. 5. Voltando ao que interessa...
  6. 6. Quem?“Rafael Ponte” “Tarso Bessa”● Desenvolvedor ● Arquiteto Java● Coordenador do ● Entusiasta Java e JSF grupo JavaSF ● Membro do Cejug● Entusiasta Java e JSF ● Trabalha na Dataprev● Consultor da TriadWorks
  7. 7. JSF tenta encapsulartoda a complexidade nodesenvolvimento webcom Java
  8. 8. A maioria dos desenvolvedores web que játrabalharam ou trabalham com algumframework “action-like” acabam tendograndes dificuldades ao desenvolveremcom JSF.
  9. 9. Criando-se então maushábitos..
  10. 10. 10º Mau hábito
  11. 11. Usar <c:if/> ou <c:when/>para esconder componentesdo usuário
  12. 12. <c:if test=”#{bean.admin}”> <h:dataTable var=”row”> <h:column> ... </h:column> </h:dataTable></c:if>
  13. 13. Usar <c:if/> ou <c:when/> SOLUÇÃO?para esconder componentesdo usuário
  14. 14. Utilizar o atributo rendered dos componentes paraescondê-los do usuário
  15. 15. <c:if test=”#{bean.admin}”> <h:dataTable rendered=”#{bean.admin}”> <h:column> ... </h:column> </h:dataTable></c:if>
  16. 16. 9º Mau hábito
  17. 17. Usar “stateless” EL no atributorendered em um componente quedispare eventos
  18. 18. <h:commandButton value=”Salvar”action=”#{bean.salvar}”rendered=”#{bean.admin}” />
  19. 19. SOLUÇÃO?
  20. 20. Garantir a avaliaçãoconsistente da EL entrerequisições.
  21. 21. session?
  22. 22. O uso indevido ou exarcebado dasession é prejudicial para aaplicação.
  23. 23. mais longo que request | mais curto que session✔ Myfaces Tomahawk [t:saveState]✔ Myfaces Orchestra✔ Myfaces Trinidad [pageFlowScope]✔ JBoss Seam✔ JBoss Richfaces [a4j:keepAlive]✔ etc
  24. 24. 8º Mau hábito
  25. 25. Usar <redirect/> nas regrasde navegação para forçar amudança da URL
  26. 26. SOLUÇÃO?
  27. 27. entendamSimplesmente como funciona um REDIRECT
  28. 28. 7º Mau hábito
  29. 29. Alterar o estado de algumcomponente no lado cliente[browser] através de javascript eesperar que isso seja “entendido”pelo JSF
  30. 30. Firebug
  31. 31. FirebugSOLUÇÃO?
  32. 32. Alterar o estado docomponente no ladoservidor via AJAX e re-renderizar o componente
  33. 33. 6º Mau hábito
  34. 34. Utilização demasiada deparâmetros de request edesenvolvimento voltado a "chaveprimária"
  35. 35. <h:dataTable value="#{users}" var="user"> <h:column ...> <h:commandLink value="X" action="#{bean.remove}" > <f:param name="id" value="#{user.id}"/> </h:commandLink> </h:column></h:dataTable>
  36. 36. public void remove(){ Integer id = new Integer( facesContext.getExternalContext(). getRequestParametersMap(). get(“id”) ); User user = search(id); if(user != null){ ... }}
  37. 37. SOLUÇÃO?
  38. 38. Pensar mais orientado aobjetos e deixar com que os componentes troquem objetos e não “chaves primárias”
  39. 39. <h:dataTable value="#{users}" var="user"> <h:column ...> <h:commandLink value="X" action="#{bean.remove}" > <f:setPropertyActionListener value="#{user}" target="#{bean.user}"/> </h:commandLink> </h:column></h:dataTable>
  40. 40. public void setUser(User user){ this.user = user;}public void remove(){ if(user != null){ // ... }}
  41. 41. É fundamental implementar osmétodos equals() e hashCode()das entidades da aplicação.
  42. 42. 5º Mau hábito
  43. 43. Usar o valor do submittedValue deum componente como se fosse ovalor real do componente.
  44. 44. ApplyRestore Process Request View Validations Values Update Render Invoke ModelResponse Application Values
  45. 45. //immediate=falseprivate UIInput input;//immediate=truepublic void calcTaxes(ActionEvent e) { String dateStr = (String) input.getSubmittedValue(); Date date = convertDate ( dateStr ); if( date.after ( otherDate ) ) { //calculate }}
  46. 46. SOLUÇÃO?
  47. 47. Dividir o formulário em subforms
  48. 48. private Date date;//immediate=falsepublic void calcTaxes() { if( date.after ( otherDate ) ) { //calculate }}
  49. 49. A quem recorrer?✔ Myfaces Tomahawk [t:subform]✔ Myfaces Trinidad [tr:subform]✔ JBoss Richfaces [a4j:region]
  50. 50. 4º Mau hábito
  51. 51. Implementam opróprio mecanismo de SEGURANÇA
  52. 52. public class LoginPhaseListener implements PhaseListener { //on RESTORE_VIEW public void afterPhase(PhaseEvent e) { if( !isLoggedIn() && !isLogin() ){ //navigate to login page } }}
  53. 53. SOLUÇÃO?
  54. 54. Utilizem um framework especializado
  55. 55. Usar /faces/* ou *.jsf quando se tempáginas em xhtml pode levar a umaexposição do código fonte.
  56. 56. 3º Mau hábito
  57. 57. Paginação deregistros na session
  58. 58. Uma das melhores maneiras dematar a escalabilidade daaplicação é a utilizaçãoindiscriminada da session
  59. 59. SOLUÇÃO?
  60. 60. Paginação sob demanda
  61. 61. 2º Mau hábito
  62. 62. Efetuar consultas de maneira INEFICIENTE
  63. 63. <h:dataTable value="#{bean.usersList}" var="user"> <h:column ...> ... </h:column></h:dataTable>
  64. 64. public class Bean { public List<User> getUsersList() { return service.findAllUsers(); }}
  65. 65. SOLUÇÃO?
  66. 66. Usar consultasem eventos ou callbacks
  67. 67. - Callback - public class Bean { @PostConstruct public void initialize(){ this.users = service.findAllUsers(); } public List<User> getUsersList() { return this.users; } }
  68. 68. - Evento -public class Bean { public void search(ActionEvent e){ this.users = service.findUsers( … ); } public List<User> getUsersList() { return this.users; }}
  69. 69. 1º Mau hábito
  70. 70. 1º -e o pior- Mau hábito
  71. 71. JSF LIFECYCLE
  72. 72. JSF LIFECYCLE A maioria dosdesenvolvedores NÃO entendem
  73. 73. JSF LIFECYCLESOLUÇÃO?
  74. 74. http://balusc.blogspot.com/2006/09/debug-jsf-lifecycle.htmlEntendam ociclo de vida
  75. 75. Concluindo..
  76. 76. Perguntas?
  77. 77. Obrigado!Rafael Ponte Tarso Bessatwitter.com/rponte twitter.com/tarsobessa

×