ICEfaces
  1. ICEfaces
  2. ICE-2751

Add rowSelector selectionListener renderResponse to component-showcase

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.7Beta1
    • Fix Version/s: 1.8DR#2, 1.8
    • Component/s: Sample Apps
    • Labels:
      None
    • Environment:
      JSP and Facelets versions of component-showcase
    • Affects:
      Sample App./Tutorial

      Description

      In ICE-2186 we removed the call to FacesContext.renderResponse() from the RowSelector's decode method. The idea being that developers would put it into their rowSelector's selectionListener, if need be.

      Since developers tend to base their apps off of the component-showcase, we should potentially add the call to FacesContext.renderResponse() into the rowSelector example. At the very least we should add a comment explaining the pros and cons of it, which are as follows:

      In applications where there are input fields with validators in the same form as a table with row selection, selecting a table row will fire the input component validators. If this is undesirable, then it's recommended to separate the table and the input fields into separate forms. If that is not possible, then you may call FacesContext.getCurrentInstance().renderResponse() from within the rowSelector's selectionListener bean method, which will skip all of the phases, including validation, up until rendering.

      When using a component, like the rowSelector, to update the contents of input components (such as when editing properties of a user, after selecting the user from a table, for example), if the input components are inside of nested UIData (any iterative container component), then the update to your model should happen in the UPDATE_MODEL or INVOKE_APPLICATION phases, which may involve re-queuing the rowSelector's selectionListener RowSelectionEvent to one of those later phases. Updating the model in an earlier phase will result in the input component values being overwritten in the beans, such that the previously selected row data will be set into the newly selected row data. This technique of re-queuing the RowSelectionEvent is not compatible with the above technique of calling FacesContext.getCurrentInstance().renderResponse(), since if you call renderResponse() there will be no UPDATE_MODEL or INVOKE_APPLICATION phases, and if you re-queue the event without calling renderResponse(), and you have validators, then the validators will fire, and if they fail there will also be no UPDATE_MODEL or INVOKE_APPLICATION phases.

        Activity

        Repository Revision Date User Message
        ICEsoft Public SVN Repository #18069 Tue Dec 16 12:36:48 MST 2008 igor.pustylnick ICE-2751 added comments reflecting different techniques, which can be used for processing selection event
        Files Changed
        Commit graph MODIFY /icefaces/trunk/icefaces/samples/component-showcase/common-web/WEB-INF/includes/examples/custom/dataTable-rowSelection.jspx
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #18068 Tue Dec 16 12:36:26 MST 2008 igor.pustylnick ICE-2751 added comments reflecting different techniques, which can be used for processing selection event
        Files Changed
        Commit graph MODIFY /icefaces/trunk/icefaces/samples/component-showcase/common-src/org/icefaces/application/showcase/view/bean/examples/component/rowSelector/RowSelectController.java

          People

          • Assignee:
            Unassigned
            Reporter:
            Mark Collette
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: