incubator-adffaces-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias We├čendorf (JIRA) <adffaces-iss...@incubator.apache.org>
Subject [jira] Updated: (ADFFACES-262) Active input text box not populated on dialog return
Date Fri, 16 Mar 2007 08:15:12 GMT

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


Mime
View raw message