[ http://issues.apache.org/jira/browse/ADFFACES-88?page=comments#action_12422694 ] Adam Winer commented on ADFFACES-88: ------------------------------------
This shouldn't really be tackled 'til JSF 1.2 and invokeOnComponent(). Also, I'd rather defer to the "Avatar" project if possible, since it offers features in this area. > Provide user with various PPR configurations > -------------------------------------------- > > Key: ADFFACES-88 > URL: http://issues.apache.org/jira/browse/ADFFACES-88 > Project: MyFaces ADF-Faces > Issue Type: Improvement > Reporter: Simon Lessard > Priority: Minor > > Currently, a PPR request will execute the whole life cycle for the complete > component tree. However, only the PPR source, its listeners and the messages > component will get rendered. This can lead to a problem when a validation > fail on a field other than the PPR source. > The most common use case is with a dynamic LoV selectOneChoice based on the > selection of another. If another field later in the form is required (and > thus most likely not filled at the time the PPR request is sent), validation > will fail and the second LoV will never get populated. > So I would suggest to add some configuration tweaks to PPR. By default it > could be the current behavior, but I see at least two other potential > configurations: > 1) Lifecycle is executed only for the PPR source, that configuration have the > draw-back of altering the model, potentially putting it in an incoherent > state. However, this configuration if rightly used would allow the previously > defined use case easily. > 2) Lifecycle is executed only for the PPR source, but the VariableResolver is > changed for a new one using placeholder for update model values. That is, > when update model is executed for the PPR source, the setValue of the > ValueBinding will rather register the EL in the VariableResolver with the new > value in a way such as if another EL read that value it will get the value > that was pushed by the PPR request instead of the one in the model, without > ever altering the true underlying model. This configuration have a draw-back > as well though. If the code required to generate the second LoV reads > directly in the model instead of using an EL, this configuration won't works. > A third configration would be to be able to push the value in the real model > but be able to roll it back if the user click on an immediate button or hit > the back button of his browser, but I don't have any serious idea on how to > achieve that easily. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
