FAQ

On 2/27/07, Volker Weber 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 <simon.kitching@rhe.co.nz>:
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.

mario.buonopane@accenture.com 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
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 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, mario.buonopane@accenture.com
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.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 9 of 18 | next ›
Discussion Overview
groupusers @
categoriesmyfaces
postedFeb 27, '07 at 10:28a
activeJun 27, '07 at 4:30p
posts18
users5
websitemyfaces.apache.org

People

Translate

site design / logo © 2017 Grokbase