You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-issues@incubator.apache.org by "Simon Lessard (JIRA)" <ad...@incubator.apache.org> on 2006/07/21 15:02:13 UTC
[jira] Created: (ADFFACES-88) Provide user with various PPR
configurations
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
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
[jira] Updated: (ADFFACES-88) Provide user with various PPR
configurations
Posted by "Simon Lessard (JIRA)" <ad...@incubator.apache.org>.
[ 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
[jira] Updated: (ADFFACES-88) Provide user with various PPR
configurations
Posted by "Matthias Weßendorf (JIRA)" <ad...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/ADFFACES-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matthias Weßendorf updated ADFFACES-88:
---------------------------------------
Affects Version/s: 1.0.1-incubating-core-SNAPSHOT
> Provide user with various PPR configurations
> --------------------------------------------
>
> Key: ADFFACES-88
> URL: https://issues.apache.org/jira/browse/ADFFACES-88
> Project: MyFaces ADF-Faces
> 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.
[jira] Commented: (ADFFACES-88) Provide user with various PPR
configurations
Posted by "Adam Winer (JIRA)" <ad...@incubator.apache.org>.
[ 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