[
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.
