[
https://issues.apache.org/jira/browse/TRINIDAD-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Weßendorf resolved TRINIDAD-546.
-----------------------------------------
Resolution: Duplicate
> Provide user with various PPR configurations
> --------------------------------------------
>
> Key: TRINIDAD-546
> URL: https://issues.apache.org/jira/browse/TRINIDAD-546
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Affects Versions: 1.0.1-incubating-core-SNAPSHOT
> 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.
-
You can reply to this email to add a comment to the issue online.
