os 10 maus habitos dos desenvolvedores jsf (justjava e cct)
DESCRIPTION
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.TRANSCRIPT
Os 10 (dez) maus hábitos dos
desenvolvedores JSF
Rafael Pontehttp://[email protected]
Tarso Bessahttp://[email protected]
Quem?
● Desenvolvedor● Coordenador do
grupo JavaSF● Entusiasta Java e JSF● Consultor da
TriadWorks
“Rafael Ponte”● Arquiteto Java● Entusiasta Java e JSF● Membro do Cejug● Trabalha na Dataprev
“Tarso Bessa”
A maioria dos desenvolvedores web que já trabalharam ou trabalham com algum framework “action-like” acabam tendo grandes dificuldades ao desenvolverem com JSF.
<c:if test=”#{bean.admin}”><h:dataTable
rendered=”#{bean.admin}”><h:column>
...</h:column>
</h:dataTable></c:if>
✔ Myfaces Tomahawk [t:saveState]✔ Myfaces Orchestra✔ Myfaces Trinidad [pageFlowScope]✔ JBoss Seam✔ JBoss Richfaces [a4j:keepAlive]✔ etc
mais longo que request | mais curto que session
Alterar o estado de algum componente no lado cliente [browser] através de javascript e esperar que isso seja “entendido” pelo JSF
<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>
public void remove(){ Integer id = new Integer( facesContext.getExternalContext(). getRequestParametersMap(). get(“id”) );
User user = search(id); if(user != null){ ... }}
Pensar mais orientado a objetos e deixar com que os
componentes troquem objetos e não “chaves
primárias”
<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>
public void setUser(User user){ this.user = user;}
public void remove(){ if(user != null){
// ... }}
RestoreView
ApplyRequest Values
ProcessValidations
RenderResponse
InvokeApplication
UpdateModelValues
//immediate=falseprivate UIInput input;//immediate=truepublic void calcTaxes(ActionEvent e) { String dateStr = (String) input.getSubmittedValue(); Date date = convertDate ( dateStr );
if( date.after ( otherDate ) ) { //calculate }}
private Date date;//immediate=falsepublic void calcTaxes() { if( date.after ( otherDate ) ) { //calculate }}
✔ Myfaces Tomahawk [t:subform]✔ Myfaces Trinidad [tr:subform]✔ JBoss Richfaces [a4j:region]
A quem recorrer?
public class LoginPhaseListener implements PhaseListener {
//on RESTORE_VIEW public void afterPhase(PhaseEvent e) { if( !isLoggedIn() && !isLogin() ){ //navigate to login page } }}
Uma das melhores maneiras de matar a escalabilidade da aplicação é a utilização indiscriminada da session
public class Bean {
@PostConstruct public void initialize(){ this.users = service.findAllUsers(); }
public List<User> getUsersList() { return this.users; }}
- Callback -
public class Bean {
public void search(ActionEvent e){ this.users = service.findUsers( … ); }
public List<User> getUsersList() { return this.users; }}
- Evento -
http://balusc.blogspot.com/2006/09/debug-jsf-lifecycle.html
Entendam o ciclo de vida