>1.) if an ajax call is made to one elment due to a change in this
element, than it would be >great to re-focus this element
>If the user is still entering info, than the next character shall be
inserted at the former caret >position. Thus, only re-focusing the
element is not enough.
>When re-rendering that element, all the input made in between the
request and the >response might get lost. This happens, if the user
types fast and/or the request/response >cycle takes some more time.
It is exactly the problem we where facing, each and every field had to
trigger a change event, which would re-render entire sections.
Enabling/disabling fields, adding or removing items from
List-Boxes/Tables and preforming validations on the user entry. The
only way we where able to handle it is by blocking the user interface
until the re-render was completed.
Maybe either f:ajax or f:focus could give the option to block the user
interface when waiting for a render response.
>2.) A data record might contain a list. This list is displayed as a
<h:datatable .../>. Every >field should be editable. And the table
shall always contain an empty last line to allow the >user to enter
additional data. Thus, if the user starts to enter some data in that
empty line, a >new line shall be added. On re-rendering, focus and
caret have to be set onto the right field >and position. Here, a
focus="@this" will solve the focus problem. But the caret position and
>data-loss problem are still not tackled. To solve this problem, it
would be nice to modify the >ajax call: Do not send the whole table,
but the new line (keeping focus on the current >element).
>The data-loss problem might be solved, if the active component is
excluded from re->rendering.
><f:ajax render="@form" renderExclude="@this"/>
>renders the form except this element (keeps it un-touched within the
DOM.
><f:ajax render="tableId" renderExclude="@current"/>
>re-renders the table with the given id, except the current cell (it's
just an idea, I haven't >checked yet, whether this would be possible at
all)
This wouldn't work well in the scenarios that I encountered, since the
point of the triggered ajax request may very well be change the state
and or content of the focus holding field.
Also where do you place the focus when the target field was disabled by
the re-render, depending on the triggering action (TAB/SHIFT+TAB) we
moved the focus to the next active or the prior active element.
The same problem exists for fields which are turned enabled by the
re-render, the browser will put the focus on the next active field,
skipping all disabled. Now if one of the skipped fields turns enabled
by the render, shouldn't that field be holding the focus?