On 2/27/07, Volker Weber <[EMAIL PROTECTED]> wrote:
Hi,
if you go the phase listener way: don't change the rendered value
beetween rendering and updateModel.
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.
* 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 think the only correct place to
change this value is in before renderResponse.
It's not the only correct place, but it is certainly a convenient one.
Most importantly, consider what happens when you navigate from one
page to another. You want the conditional logic that sets the
rendered flag for the *destination* page to be executed, not any logic
inside the origin page. (By the way, this is exactly the kind of use
case that the prerender() method of the Shale ViewController[1] API is
for.)
And i think this should be done by updateing properties of a bean to
which the rendered attribute is bind via valueBinding, not by climbing
through the uitree.
That would generally be my preference as well. Besides not having to
walk the component tree (or call findComponent() and have JSF walk it
for you), this means you can just define a boolean getter method that
implements the condition checking, and inside that method you don't
have to reference any JSF APIs ... just the business logic APIs on
which you base the decision.
Regards,
Volker
Craig
[1] http://shale.apache.org/shale-view/
2007/2/27, Simon Kitching <[EMAIL PROTECTED]>:
> This does sound like a pretty weird scenario. You want to change the
> behaviour of the application but don't want to change the application?
>
> However I guess this could be done in a PhaseListener. After
> restore-view, look in a database (for example) to see if there are any
> "overrides" for the current view, and if so retrieve a set of
> (component-id, el-expression) values. Then walk the current component
> tree and for each component that has an id that matches one of the
> "overrides", evaluate the EL-expression and update the component's
> rendered state.
>
> A custom UIViewRoot component might also work..
>
> I can't really see *why* you would want to do this, though. Seems much
> easier to just update the JSP/facelets file to add the rendered attribute.
>
> A system like this might make more sense for "security" reasons, ie
> ensure that every field that is not "authorised" for the current user is
> automatically not rendered. Tomahawk does have the "visibleOnUserRole"
> attribute for this but a PhaseListener approach also has appeal. of
> course this depends on being able to somehow identify the components;
> having the attribute on the component tag itself avoids that issue.
>
> [EMAIL PROTECTED] wrote:
> > Yes I know, using rendered, valueBinding and managed bean I can do it,
> > but to use these options I have to project the application to managed
> > this cases. Suppose I have developed an application and in a page I have
> > a textbox that, at develop design, noone supposed this component could
> > be hide in some situation...so the text box is always rendered. In this
> > case I don't have no programmatic "if" and no EL expression. How can I
> > hide this texbox without modify the code? I was thinking to implement a
> > my UIViewRoot, override the component in faces-config to force to use my
> > UIViewRoot and put inside my UIViewRoot all the logic.....is it
> > possible? Is it correct?
> >
> > -----Original Message-----
> > From: Mike Kienenberger [mailto:[EMAIL PROTECTED]
> > Sent: 27 febbraio 2007 21.23
> > To: MyFaces Discussion
> > Subject: Re: Change visibility dinamically
> >
> > Oops. You're right, Simon. It could be set programmically. I
> > still think it's a bad design, but that's just my opinion.
> >
> > On 2/27/07, Simon Kitching <[EMAIL PROTECTED]> wrote:
> >> Not sure what you mean, Mike.
> >>
> >> Every UIComponent has a setRendered(boolean) method that can be called
> >> to specify whether that component is rendered or not. This method
> > could
> >> certainly be called from a PhaseListener.
> >>
> >> Note that there is a slight flaw in the design of this method in my
> >> opinion; the rendered property can be specified as either an EL
> >> expression (ie stored as a ValueBinding) or can be a literal value set
> >> via setRendered(). If a value-binding is used then setRendered() can
> >> later be used to override that; however once rendered has been set
> > using
> >> setRendered, there is no way to go back to using an EL expression.
> > In
> >> other words, once you've decided to manually control the rendered
> > state
> >> you cannot go back to using the original EL rendered expression.
> >>
> >> One way around this would be to use
> >> // create a ValueBinding for the expression #{true}
> >> setValueBinding("rendered", vb);
> >> rather than
> >> setRendered(true);
> >>
> >> Cheers,
> >>
> >> Simon
> >>
> >> Mike Kienenberger wrote:
> >>> You can only set the rendered property of a component from the
> > values
> >>> of a managed bean (unless you're using facelet functions or
> > customized
> >>> el resolvers). Your managed bean can call whatever java code you
> >>> want it to.
> >>>
> >>> If you give more specific details of what you're trying to
> > accomplish,
> >>> maybe we can help you more.
> >>>
> >>>
> >>> On 2/27/07, [EMAIL PROTECTED]
> >>> <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>>
> >>>>
> >>>> I wanna change the behavior of my application changing the
> > visibility of
> >>>> some component basing of specific rules but I don't wan put this
> > logic
> >>>> in my
> >>>> Managed Bean but externally. May be implementing a Phase Listener
> > can
> >>>> help
> >>>> me to do this? In wich Phase should I set the visible property of
> > my
> >>>> components?
> >>>>
> >
> >
> > 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.
>
>
