|
|
Tsc, tsc...
Impressionante como o pessoal homologa software totalmente trash e deixa de fora algumas coisas que realmente fazem a diferença...
[ ]s
Davinir
Em 12 de março de 2010 16:01, Gustavo Lira e Silva <guga.lista@xxxxxxxxx> escreveu:
o #{mb.docs} é chamado o tempo todo na página, inúmeras vezes...
Desta forma então a perfomance vai cair muito. Deus me livre, deve ter um jeito melhor de fazer.
O problema é que nao posso utilizar Injeção de dependência (penso que resolveria o problema) do Spring ou Seam pq não existe estes softwares homologados...
Em 12 de março de 2010 10:15, Davinir F Campos Jr <davinir.jr@xxxxxxxxx> escreveu:
Gustavo,
O getDocs será executado cada vez que o JSF encontrar uma EL #{mb.docs...}, cara.
Pelo que eu contei aqui, são pelo menos 13 vezes só pra colocar o elemento na árvore de componentes.
:-)
É sobre isso que aquele post do Rafael fala.
Se você não se importar com esse design, não há muito problema (performance, não é?).
[ ]s
Davinir
Em 12 de março de 2010 02:05, Rafael Ponte <rponte@xxxxxxxxx> escreveu:
Bem, seria necessário eu ver restante da página. A EL #{mb.docs...} é chamada apenas nesse h:commandLink mesmo?
2010/3/12 Gustavo Lira e Silva <guga.lista@xxxxxxxxx>
Desculpe, postei errado.
ele entra várias vezes no método que retorna a instancia de docs (mb.docs)
o método é este
public DocumentosBean getDocs() {
PortletSession sessao = (PortletSession) FacesContext.getCurrentInstance().getExternalContext().getSession(false);
DocumentosBean d = (DocumentosBean) sessao.getAttribute("docs",PortletSession.APPLICATION_SCOPE);
if(d != null){
this.docs = d;
}
return docs;
}
Em 12 de março de 2010 01:09, Rafael Ponte <rponte@xxxxxxxxx> escreveu:
Não existe o método getMb() nesse exemplo. Alias, o que é esse "mb" aí? É o atributo var do h:dataTable?2010/3/12 Gustavo Lira e Silva <guga.lista@xxxxxxxxx>
Por exemplo, veja esta parte: <t:updateActionListener value="#{true}" property="#{mb.docs.mostraDadosPessoais}"
/>
na expressão existe o ManagedBean chamado mb.
no método get dele public ManagedBean getMb();
Este método esta sendo acessado mais de 20 vezes na requisição...
Em 12 de março de 2010 01:00, Rafael Ponte <rponte@xxxxxxxxx> escreveu:
Não entendi!2010/3/12 Gustavo Lira e Silva <guga.lista@xxxxxxxxx>
No get que retornar o bean MB
Em 12 de março de 2010 00:49, Rafael Ponte <rponte@xxxxxxxxx> escreveu:
Ok, deixando o design dos managed beans um pouco de fora.
Em que método exatamente ele está entrando várias vezes?
2010/3/12 Gustavo Lira e Silva <guga.lista@xxxxxxxxx>
Já lí Rafael, mas na verdade não foi eu quem desenvolveu, e a aplicação já está quase pronta. o que poderia ser mudado, é não tratar isto na página e sim numa classe normal mesmo.
Mas fora isso (código ruim) eu não entendo o motivo de entrar tantas vezes na classe java
Em 11 de março de 2010 13:48, Rafael Ponte <rponte@xxxxxxxxx> escreveu:
Vale a pena ler este artigo,
http://www.rponte.com.br/2009/08/27/managed-beans-nao-complique-simplifique/
:-)
2010/3/11 Gustavo Lira e Silva <guga.lista@xxxxxxxxx>
Pessoal, eu entendo que no ciclo de vida do jsf ele entra várias vezes no mesmo método, e que não devemos colocar regras pesadas nestes métodos get's.
Porém a quantidade de vezes que o jsf está entrando lá na classe Java é um absurod, posso chutar que ele entra mais de 30 vezes...
o código que estou utilizando no jsp é este:
<h:form>
<t:commandLink styleClass="#{mb.docs.cssDadosPessoais}" >Dados Pessoais
<t:updateActionListener value="#{true}" property="#{mb.docs.mostraDadosPessoais}" />
<t:updateActionListener value="#{false}" property="#{mb.docs.mostraDadosConjuge}" />
<t:updateActionListener value="#{false}" property="#{mb.docs.mostraFonteRenda}" />
<t:updateActionListener value="#{false}" property="#{mb.docs.mostraDespesas}" />
<t:updateActionListener value="#{false}" property="#{mb.docs.mostraFormFgts}" />
<t:updateActionListener value="#{false}" property="#{mb.docs.mostraDadosVendedor}" />
<t:updateActionListener value="#{'linkDocumentos imgrpl mn_dadospessoais on'}" property="#{mb.docs.cssDadosPessoais}" />
<t:updateActionListener value="#{'linkDocumentos imgrpl mn_dadosconjuge'}" property="#{mb.docs.cssDadosConjuge}" />
<t:updateActionListener value="#{'linkDocumentos imgrpl mn_fonterenda'}" property="#{mb.docs.cssFonteRenda}" />
<t:updateActionListener value="#{'linkDocumentos imgrpl mn_despesasfamiliares'}" property="#{mb.docs.cssDespesasFamiliares}" />
<t:updateActionListener value="#{'linkDocumentos imgrpl mn_dadosfgts'}" property="#{mb.docs.cssDadosFGTS}" />
<t:updateActionListener value="#{'linkDocumentos imgrpl mn_dadosvendedor'}" property="#{mb.docs.cssDadosVendedor}" />
</t:commandLink>
</h:form>
You received this message because you are subscribed to the Google
Groups "javasf: JavaServer Faces Group" group.
To post to this group, send email to javasf@xxxxxxxxxxxxxxxx
--
Rafael Ponte
http://www.rponte.com.br
--
You received this message because you are subscribed to the Google
Groups "javasf: JavaServer Faces Group" group.
To post to this group, send email to javasf@xxxxxxxxxxxxxxxx
-- Rafael Ponte http://www.rponte.com.br
--
http://groups.google.com/group/javasf
You received this message because you are subscribed to the Google
Groups "javasf: JavaServer Faces Group" group.
To post to this group, send email to javasf@xxxxxxxxxxxxxxxx
-- Rafael Ponte http://www.rponte.com.br
--
http://groups.google.com/group/javasf
You received this message because you are subscribed to the Google
Groups "javasf: JavaServer Faces Group" group.
To post to this group, send email to javasf@xxxxxxxxxxxxxxxx
-- Rafael Ponte http://www.rponte.com.br
--
http://groups.google.com/group/javasf
You received this message because you are subscribed to the Google
Groups "javasf: JavaServer Faces Group" group.
To post to this group, send email to javasf@xxxxxxxxxxxxxxxx
--
http://groups.google.com/group/javasf
You received this message because you are subscribed to the Google
Groups "javasf: JavaServer Faces Group" group.
To post to this group, send email to javasf@xxxxxxxxxxxxxxxx
|
|