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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > 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, [EMAIL PROTECTED] > <[EMAIL PROTECTED]>: > > 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> wrote: > > > 2007/2/27, Craig McClanahan <[EMAIL PROTECTED]>: > > > > On 2/27/07, Volker Weber <[EMAIL PROTECTED]> 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.
