> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 05 augustus 2008 17:14 > To: MyFaces Discussion > Subject: Re: Setter not called for conditionally rendered fields > > When someone replies in bottom-posting style, it is rather > rude to put your reply on top. I'll reformat this email this time...
Sorry about that. I wasn't aware of this. > > [EMAIL PROTECTED] schrieb: > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [_mailto:[EMAIL PROTECTED] > > Sent: 05 augustus 2008 16:24 > > To: MyFaces Discussion > > Subject: Re: Setter not called for conditionally rendered fields > > > > [EMAIL PROTECTED] schrieb: > > > > > > Hi, > > > > > > I keep running into a problem where the setter of a field (say/ > > > Field > > > 1/) in my backing bean (in request scope) that is rendered > > > conditionally is not called. > > > > > > I think what happens is that Trinidad evaluates the rendered > > > condition to determine if the setter should be called. My backing > > > bean is sort of stateless and needs to be filled with > data from the form. > > > > > > Because the condition depends on another field (/Field 2/) in the > > > backing bean, the outcome of this evaluation will only be > correct if > > > the setter of Field 2 was already called, which may or may not be > > > the case. So for some fields it will work but for other > it will not. > > > > > > How can I get around this? > > > > > It is standard behaviour for JSF components to evaluate > their "rendered" > > expression, and NOT write to the "value" property if > rendered is false. > > This is nothing to do with Trinidad. > > > > If you have a view where the rendered property of a > component depends > > upon the user-provided value of another field, then I don't > think that > > is going to work. I wouldn't think it even depends on > component order > > in the page; an EL expression uses only values that have > already been > > pushed into the model, but a component uses the "rendered" state to > > determine whether to accept data from the posted form in an earlier > > phase, ie before any values are pushed to the model. > > > > See specification/javadoc for methods UIComponent.decode and > > UIComponent.processDecodes. > > > > I can't think of any solution for this. And I don't really > understand > > why you are trying to do this either. You are trying to switch the > > "rendered" state of a component in the middle of the postback phase. > > > > Why? JSF really expects the rendered state during postback to match > > the rendered state that existed during the earlier render phase. > > > > As a side-point, does the JSF spec actually say that "rendered" EL > > expressions should be re-evaluated during postback? That's what > > MyFaces currently does, but it seems to me that the > true/false state > > should really be part of the component's saved state and > the restored > > value simply used during postback (and recalculated in > render phase). > > That doesn't make any difference to the original question however. > > > I'm not trying to do anything in the middle of the postback. > > Suppose I have a request scope bean that has two fields: > > boolean displayField; > String inputField; > > The inputField is displayed when displayField is true. > > displayField is initialized the first time with some request > parameter is the URL that displays the form page. > > To be able to retain the value of displayField when the form > is posted I put a hidden field in the form that is bound to > displayField. > > When, on entering the form page displayField is true the > field will be displayed. But when I fill in the field and > post the form it is not set on the backing bean if > displayField hasn't been set yet. > > It seems to me that what I'm trying to do is trivial and not > uncommon. > Is there another method of accomplishing this? How can I make > sure the rendered state is saved without storing something in > session scope. > > The problem here is with this hidden field. This is "hacking" > JSF, and JSF doesn't like to be hacked. > > A JSF component's rendered state can either be embedded in > the component, or an EL expression can be used to store the > rendered state "external" to the component, in a backing bean. > > When the rendered state is a constant, then the state is > maintained by the component. When rendered state can change, > you *can* use component bindings to access a component, then > set its rendered state via a method call in which case it > will remember this automatically, but component bindings are > not terribly elegant, so I would not recommend this. > > The alternative *is* to use stateful backing beans of some > kind. But "session" scope is only the crudest stateful > solution, and has a lot of drawbacks. For simple apps this is > an option, but for anything non-trivial try one of the below. > > * MyFaces Tomahawk t:aliasBean. Quite a nice solution for > simple apps; it's rather like your "hidden field" approach, > but properly integrated into JSF. > * seam conversation scope > * spring webflow conversation scope > * trinidad flow scope > * myfaces orchestra > > > @Simon: I think your last point makes a lot of sense. If a > component was rendered its value should be updated in the > model. Why wouldn't that solve this problem? > > If your problem is that your component is ignoring user input > because you use an EL expression which evaluated to TRUE > during rendering, but is evaluating to FALSE during postback > (due to a fresh instance of the backing bean being used) then > yes this might actually solve this particular problem. But I > don't think a patch is likely to be applied to myfaces-core > on this anytime soon; this change would need some careful > thought re backwards compatibility. But I have raised this on > the dev list. If someone could check how Sun Mojarra behaves > in this respect, then that would help progress on this > (generally we try to be compatible with Mojarra unless there > is a good reason to do otherwise). > > Regards, > Simon > > Thanks for the explanation and suggestions. Regards, Freek Segers ================================================ The information transmitted via this e-mail is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
