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

          Hide
          Thomas Greve added a comment -

          In fact, there seem to be two bugs related to this: The early RowSelectorEvent (fixed in 1.7.1 according to Mark Collette) and additional ValueChangeEvents, which should not be fired at all, cf. ICE-3156

          Show
          Thomas Greve added a comment - In fact, there seem to be two bugs related to this: The early RowSelectorEvent (fixed in 1.7.1 according to Mark Collette) and additional ValueChangeEvents, which should not be fired at all, cf. ICE-3156
          Hide
          Michael Voegele added a comment -

          Thanks Thomas for your answer. What is described in ICE-3156 is exactly what happens. There are additional ValueChangeEvents, which should not be fired at all. So I totally agree to you, this issue depends on ICE-3156, but has nothing to do with ICE-1445. Will this issue also be solved in 1.7.1?

          Show
          Michael Voegele added a comment - Thanks Thomas for your answer. What is described in ICE-3156 is exactly what happens. There are additional ValueChangeEvents, which should not be fired at all. So I totally agree to you, this issue depends on ICE-3156 , but has nothing to do with ICE-1445 . Will this issue also be solved in 1.7.1?
          Hide
          Thomas Greve added a comment -

          Ask Mark Collette and vote for it.

          Show
          Thomas Greve added a comment - Ask Mark Collette and vote for it.
          Hide
          Ken Fyten added a comment -

          Marking as Closed / Invalid as part of legacy ICEfaces ICE / Compat component JIRA cleanup.

          Note: This issue may be resolved in a newer ICEfaces release, available here: http://www.icesoft.org/java/downloads/icefaces-downloads.jsf

          If the issue persists with the current ICEfaces release, please create a new JIRA for it.

          Show
          Ken Fyten added a comment - Marking as Closed / Invalid as part of legacy ICEfaces ICE / Compat component JIRA cleanup. Note: This issue may be resolved in a newer ICEfaces release, available here: http://www.icesoft.org/java/downloads/icefaces-downloads.jsf If the issue persists with the current ICEfaces release, please create a new JIRA for it.

            People

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

              Dates

              • Created:
                Updated:
                Resolved: