Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Message-ID: <231630550.1225285184383.JavaMail.jira@brutus>
Date: Wed, 29 Oct 2008 05:59:44 -0700 (PDT)
From: =?utf-8?Q?Matthias_We=C3=9Fendorf_=28JIRA=29?= <dev@myfaces.apache.org>
To: dev@myfaces.apache.org
Subject: [jira] Resolved: (TRINIDAD-546) Provide user with various PPR
 configurations
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/TRINIDAD-546?page=3Dcom.atlass=
ian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matthias We=C3=9Fendorf 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 comple=
te component tree. However, only the PPR source, its listeners and the mess=
ages component will get rendered. This can lead to a problem when a validat=
ion fail on a field other than the PPR source.=20
> The most common use case is with a dynamic LoV selectOneChoice based on t=
he selection of another. If another field later in the form is required (an=
d thus most likely not filled at the time the PPR request is sent), validat=
ion 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 conf=
igurations:
> 1) Lifecycle is executed only for the PPR source, that configuration have=
 the draw-back of altering the model, potentially putting it in an incohere=
nt state. However, this configuration if rightly used would allow the previ=
ously defined use case easily.
> 2) Lifecycle is executed only for the PPR source, but the VariableResolve=
r 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 V=
alueBinding will rather register the EL in the VariableResolver with the ne=
w value in a way such as if another EL read that value it will get the valu=
e that was pushed by the PPR request instead of the one in the model, witho=
ut 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 work=
s.
> A third configration would be to be able to push the value in the real mo=
del 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 h=
ow to achieve that easily.

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.