[ http://issues.apache.org/jira/browse/ADFFACES-88?page=all ]
Simon Lessard updated ADFFACES-88:
----------------------------------
Priority: Minor (was: Major)
This is not a major issue
> 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
