incubator-adffaces-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Lessard (JIRA)" <adffaces-iss...@incubator.apache.org>
Subject [jira] Updated: (ADFFACES-88) Provide user with various PPR configurations
Date Fri, 21 Jul 2006 15:04:19 GMT
     [ 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

        

Mime
View raw message