[jira] Updated: (ADFFACES-262) Active input text box not populated on dialog return

["Matthias Weßendorf (JIRA)" <ad...@incubator.apache.org>]

     [ https://issues.apache.org/jira/browse/ADFFACES-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matthias Weßendorf updated ADFFACES-262:
----------------------------------------

        Fix Version/s: 1.0.0-incubating-core
    Affects Version/s: 1.0.0-incubating-core

> Active input text box not populated on dialog return
> ----------------------------------------------------
>
>                 Key: ADFFACES-262
>                 URL: https://issues.apache.org/jira/browse/ADFFACES-262
>             Project: MyFaces ADF-Faces
>          Issue Type: Improvement
>    Affects Versions: 1.0.0-incubating-core
>         Environment: N/A
>            Reporter: Olivier Lafontaine
>            Priority: Minor
>             Fix For: 1.0.0-incubating-core
>
>         Attachments: UIXCommandTemplate.patch
>
>
> Objective is to populate an input text from a value entered/picked in a dialog. There's two way to accomplish this, either by binding the input text component in your bean (1) or by using having the input text value binded to a bean property (2). Both works if the input text is disabled, however only (1) can work if the input text is active. 
> To make (1) work with an active input text, you have to clear the submitted value from the input text when the return listener is invoked. This technique is documented on Oracle website (http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/doc/devguide/dialogs.html).
> Since a value submitted by a disabled input text is ignored, technique (2) works only for disabled inputs.
> The reason behind the submitted value thing is because return events are processed at the end of the "Apply Request Values" phase and FacesContext#renderResponse() is called afterward, see UIXCommand#broadcast(FacesEvent).
> From my understanding of the framework, I believe it is incorrect to process return events at the end of the "Apply Request Values" phase. When a dialog is closed, the calling page is submitted to execute an action, the return action. The return action is no different than a normal action so why process it sooner? In fact, the return action should substitute to any other declared actions for the command, aka normal actions should not be processed (this is already implemented in the framework see CommandLinkRenderer#decode(FacesContext, UIComponent)). 
> I have attached a patch to allow technique (2) to work even if input text is not disabled. The patch modifies the UIXCommandTemplate file to handle a return event the same way as an action event in the queueEvent(FacesEvent) method. 
> Note that if the command is marked as immediate (="true") to bypass validation (of required fields for example), then you either have to mark the input text as immediate too or use technique (1).

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