ICEfaces
  1. ICEfaces
  2. ICE-3192

RowSelection in a Table leads to ValueChangeEvent of InputFields showing the selected data

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 1.6.1, 1.7
    • Fix Version/s: None
    • Component/s: ICE-Components
    • Labels:
      None
    • Environment:
      Tomcat 6
    • Workaround Description:
      Hide
      As I have nothing to do in the Listener of the RowSelectorEvent, I found some kind of a workaround, but I am very unhappy with this...

      When selecting a row, the RowSelectorEvent Listener is processed before the wrongly executed ValueChangeListeners. So in the RowSelectorEvent Listener I break the Event Execution Chain by calling renderResponse(). Because of this, the Getters are not called anymore and this has to be forced by using getViewRoot().getChildren().clear().

      public void selectRow(RowSelectorEvent event) throws Exception {
      // TODO replace this hack...
      FacesContext.getCurrentInstance().renderResponse();
      FacesContext.getCurrentInstance().getViewRoot().getChildren().clear();
      }
      Show
      As I have nothing to do in the Listener of the RowSelectorEvent, I found some kind of a workaround, but I am very unhappy with this... When selecting a row, the RowSelectorEvent Listener is processed before the wrongly executed ValueChangeListeners. So in the RowSelectorEvent Listener I break the Event Execution Chain by calling renderResponse(). Because of this, the Getters are not called anymore and this has to be forced by using getViewRoot().getChildren().clear(). public void selectRow(RowSelectorEvent event) throws Exception { // TODO replace this hack... FacesContext.getCurrentInstance().renderResponse(); FacesContext.getCurrentInstance().getViewRoot().getChildren().clear(); }

      Description

      Hi to everybody

      I have a problem with the table component and a view under the table, showing more details of the object of the selected row. There are InputFields in the detail view, where the users should also be able to change the values of the object.

      I am not sure, if this is really an issue, if not, I would very much appreciate, if you could tell me how to solve the problem.

      I have made a template for a table, that can be used in a dynamic way. There the Selection is assigned as follows:
      <!-- dynamische Spalten -->
      <ice:columns id="#{id}columnDataModel"
      value="#{table.columnDataModel}" var="column">

      <!-- Selector auf die Zeilen der dynamischen Spalten -->
      <ice:panelGroup rendered="#{table.tableProperties.visible}">
      <ice:rowSelector id="#{id}selected" value="#{table.selected}"
      multiple="#{table.tableProperties.multipleSelection}"
      selectedClass="klcRowSelSelected"
      mouseOverClass="klcRowSelMouseOver"
      selectionListener="#{table.tableListener.selectRow}" />
      </ice:panelGroup>

      The table.selected is assigned to a method that looks as follows:
      public void setSelected(boolean selected) {
      // TODO issue solved with ICEfaces 1.7 -> delete when verified
      // if(getColumnDataModel().getRowIndex() == 0) {
      if(selected) {
      selectedElements.add(getCurrentTableRow());
      } else {
      selectedElements.remove(getCurrentTableRow());
      }
      // }
      }

      where selectedElements is an ArrayList. This works for Single as well as Multiple Selection.

      In case of Single Selection, I can get the selected element as:
      public TableRow getSelectedElement() {
      if(selectedElements.isEmpty()) {
      return null;
      }
      return selectedElements.get(0);
      }

      As described before, under the table there are InputFields showing the details of the selected element. The InputFields are tied to another backing bean.

      In a first version, I had PartialSubmit = true on those fields, so if somebody changes values in the InputFields, they are written back into the object.

      public String getPersonName() {
      return getPersonenBestand().getSelectedElement().getExample_header2();
      }

      public void setPersonName(String s) {
      getPersonenBestand().getSelectedElement().setExample_header2(s);
      }

      The Method getPersonenBestand() gives a reference to the backing bean of the table, getSelectedElement() gives the element selected at the moment.


      Now to the problem:
      1. Table is shown, an element gets selected, InputFields show the correct values of the selected object, all fine.
      2. A value is changed in an InputField, changes of the selected object are reflected back into the table (above setter is called). The change can also be seen in the table, all fine.
      3. ANOTHER row gets selected. What happens now is that first the setters are called (correct), then the new selected object is set (setSelected(boolean) is called on the table backing bean) (correct), and third the setters are called again on the new selected object, but with the values from the old object (WRONG). So just selecting another row leads to an overwrite of its attributes. This should not happen.


      In a second version, I made value change listeners for the InputFields and did nothing anymore in the setters:

      In the value change listener, I set the value of the field on the object by reflection, which worked fine. Changes were also reflected back into the table. But just selecting another row led to the same problem. Just selecting another row led to a ValueChangeEvent of the InputFields, which, in my opinion is false.

      As I have nothing to do in the Listener of the RowSelectorEvent
      public void selectRow(RowSelectorEvent event) throws Exception {
      // TODO replace this hack...
      FacesContext.getCurrentInstance().renderResponse();
      FacesContext.getCurrentInstance().getViewRoot().getChildren().clear();
      }


      Before I had ICEfaces version 1.6.1, where I saw the error for the first time. I therefore upgraded to version 1.7, to see whether the error persists. I am unsure, if the issue http://jira.icefaces.org/browse/ICE-1445 is about the same, but it is quite different, I believe.

      Thanks a lot for your help! Maybe it is not an issue, but you can explain how to solve the problem.

      Michael

        Issue Links

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              Michael Voegele
            • Votes:
              3 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: