You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by ma...@accenture.com on 2007/05/21 13:18:03 UTC
RE: Change visibility dinamically
I have tested this solution and does work!
Any one feel something wrong in this solution?
Please send me some feedback to the solution.
Regards
Mario Buonopane
-----Original Message-----
From: weber.volker@googlemail.com [mailto:weber.volker@googlemail.com]
On Behalf Of Volker Weber
Sent: 28 febbraio 2007 12.26
To: MyFaces Discussion
Subject: Re: Change visibility dinamically
You can overwite encodeBegin AND encodeEnd doing the following:
in encodeBegin:
backup and replace the responseWriter
in encodeEnd:
throw away the replaced responseWriter,
do your rendered stuff
reset the backuped original responseWriter
do the original encodeBegin, encodeChildren(), and the original
encodeEnd() again.
This should do render and create the ComponentTree, discard the result
of rendering, do your stuff, rerender the uiTree.
Regards,
Volker
2007/2/28, mario.buonopane@accenture.com
<ma...@accenture.com>:
> Yes I agree. Could I have a chance to hook if I use a my
implementation
> of UIViewRoot overriding encodeBegin method?
>
> Regards,
> Mario
>
> -----Original Message-----
> From: weber.volker@googlemail.com [mailto:weber.volker@googlemail.com]
> On Behalf Of Volker Weber
> Sent: 28 febbraio 2007 09.48
> To: MyFaces Discussion
> Subject: Re: Change visibility dinamically
>
> Hi,
>
> in jsf 1.1 with jsp (don't know how it is in faclets) the component
> creation is done while rendering, so there is no chance to hook in
> between.
>
> Regards,
> Volker
>
> 2007/2/28, mario.buonopane@accenture.com
> <ma...@accenture.com>:
> > I have tested before render response but does'nt work because, the
> first
> > time I call the page, in befer render response phase the view root
is
> > empty.
> >
> > -----Original Message-----
> > From: craigmcc@gmail.com [mailto:craigmcc@gmail.com] On Behalf Of
> Craig
> > McClanahan
> > Sent: 27 febbraio 2007 23.50
> > To: MyFaces Discussion
> > Subject: Re: Change visibility dinamically
> >
> > On 2/27/07, Volker Weber <v....@inexso.de> wrote:
> > > 2007/2/27, Craig McClanahan <cr...@apache.org>:
> > > > On 2/27/07, Volker Weber <v....@inexso.de> wrote:
> > > >
> > > > The places where the rendered flag is referenced are actually:
> > > >
> > > > * In Apply Request Values ... decoding of request parameters
> > > > will not occur if rendered (or visible) is set to false.
> > >
> > > also in processValidations and processUpdates, both are skiped if
> > > rendred is set to false.
> > >
> > > >
> > > > * In Render Response ... rendering will be completely skipped
> > > > if rendered is set to false.
> > > >
> > > > In between these times, the rendered property is most likely not
> > being
> > > > referenced, so changes are safe.
> > >
> > > I don't think you get the expected results if you change on other
> > > places than between after updateModel and before renderResponse.
> > > In case of validation/conversion errors all of them exept before
> > > renderResponse are skipped.
> > >
> >
> > Good catch ... I forgot to check the processXxxx methods for those
> > phases.
> >
> > So, the advice that before render response seems like the point to
> > change the value stands.
> >
> > > Regards,
> > > Volker
> > >
> >
> > Craig
> >
> >
> > This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise private information. If you
have
> received it in error, please notify the sender immediately and delete
> the original. Any other use of the email by you is prohibited.
> >
>
>
> This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete
the original. Any other use of the email by you is prohibited.
>
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
RE: Change visibility dinamically
Posted by ma...@accenture.com.
I'm sorry but I'm trying this solution and I'm receiving this exception:
[27/06/07 18.26.04:356 CEST] 00000028 ServletWrappe E SRVE0068E:
Impossibile richiamare il metodo service() per il servlet
/template/template_prototipo.jsp. Eccezione generata :
java.lang.IllegalStateException: Client-id : scroll_1first is duplicated
in the faces tree. Component : content:formRicercaPol:scroll_1first,
path: {Component-Path : [Class:
org.apache.shale.view.faces.ShaleViewRoot,ViewId:
/ricerche/ricercaPolizze.jsp][Class:
javax.faces.component.UINamingContainer,Id: content][Class:
prova.MyHtmlForm,Id: formRicercaPol][Class:
org.apache.myfaces.component.html.ext.HtmlPanelGrid,Id: tabella1][Class:
org.apache.myfaces.custom.datascroller.HtmlDataScroller,Id:
scroll_1][Class: javax.faces.component.html.HtmlCommandLink,Id:
scroll_1first]}
at
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicate
Ids(JspStateManagerImpl.java:329)
at
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicate
Ids(JspStateManagerImpl.java:341)
What I have done is override encodeBegin and encodeEnd of
javax.faces.HtmlForm component in this way:
public void encodeBegin(FacesContext context) throws IOException
{
this.oldResponseWriter = context.getResponseWriter();
ResponseWriter newResWri = new DummyResponseWriter();
context.setResponseWriter(newResWri);
super.encodeBegin(context);
}
public void encodeEnd(FacesContext context) throws IOException {
context.setResponseWriter(this.oldResponseWriter);
super.encodeBegin(context);
super.encodeChildren(context);
super.encodeEnd(context);
}
Please help me
Mario
-----Original Message-----
From: mario.buonopane@accenture.com
[mailto:mario.buonopane@accenture.com]
Sent: 21 maggio 2007 13.18
To: users@myfaces.apache.org
Subject: RE: Change visibility dinamically
I have tested this solution and does work!
Any one feel something wrong in this solution?
Please send me some feedback to the solution.
Regards
Mario Buonopane
-----Original Message-----
From: weber.volker@googlemail.com [mailto:weber.volker@googlemail.com]
On Behalf Of Volker Weber
Sent: 28 febbraio 2007 12.26
To: MyFaces Discussion
Subject: Re: Change visibility dinamically
You can overwite encodeBegin AND encodeEnd doing the following:
in encodeBegin:
backup and replace the responseWriter
in encodeEnd:
throw away the replaced responseWriter,
do your rendered stuff
reset the backuped original responseWriter
do the original encodeBegin, encodeChildren(), and the original
encodeEnd() again.
This should do render and create the ComponentTree, discard the result
of rendering, do your stuff, rerender the uiTree.
Regards,
Volker
2007/2/28, mario.buonopane@accenture.com
<ma...@accenture.com>:
> Yes I agree. Could I have a chance to hook if I use a my
implementation
> of UIViewRoot overriding encodeBegin method?
>
> Regards,
> Mario
>
> -----Original Message-----
> From: weber.volker@googlemail.com [mailto:weber.volker@googlemail.com]
> On Behalf Of Volker Weber
> Sent: 28 febbraio 2007 09.48
> To: MyFaces Discussion
> Subject: Re: Change visibility dinamically
>
> Hi,
>
> in jsf 1.1 with jsp (don't know how it is in faclets) the component
> creation is done while rendering, so there is no chance to hook in
> between.
>
> Regards,
> Volker
>
> 2007/2/28, mario.buonopane@accenture.com
> <ma...@accenture.com>:
> > I have tested before render response but does'nt work because, the
> first
> > time I call the page, in befer render response phase the view root
is
> > empty.
> >
> > -----Original Message-----
> > From: craigmcc@gmail.com [mailto:craigmcc@gmail.com] On Behalf Of
> Craig
> > McClanahan
> > Sent: 27 febbraio 2007 23.50
> > To: MyFaces Discussion
> > Subject: Re: Change visibility dinamically
> >
> > On 2/27/07, Volker Weber <v....@inexso.de> wrote:
> > > 2007/2/27, Craig McClanahan <cr...@apache.org>:
> > > > On 2/27/07, Volker Weber <v....@inexso.de> wrote:
> > > >
> > > > The places where the rendered flag is referenced are actually:
> > > >
> > > > * In Apply Request Values ... decoding of request parameters
> > > > will not occur if rendered (or visible) is set to false.
> > >
> > > also in processValidations and processUpdates, both are skiped if
> > > rendred is set to false.
> > >
> > > >
> > > > * In Render Response ... rendering will be completely skipped
> > > > if rendered is set to false.
> > > >
> > > > In between these times, the rendered property is most likely not
> > being
> > > > referenced, so changes are safe.
> > >
> > > I don't think you get the expected results if you change on other
> > > places than between after updateModel and before renderResponse.
> > > In case of validation/conversion errors all of them exept before
> > > renderResponse are skipped.
> > >
> >
> > Good catch ... I forgot to check the processXxxx methods for those
> > phases.
> >
> > So, the advice that before render response seems like the point to
> > change the value stands.
> >
> > > Regards,
> > > Volker
> > >
> >
> > Craig
> >
> >
> > This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise private information. If you
have
> received it in error, please notify the sender immediately and delete
> the original. Any other use of the email by you is prohibited.
> >
>
>
> This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete
the original. Any other use of the email by you is prohibited.
>
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete
the original. Any other use of the email by you is prohibited.
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.