ICEfaces
  1. ICEfaces
  2. ICE-8817

ace:dataTable add post-filter, post-pagination and post-sorting events

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 3.2
    • Fix Version/s: 3.3
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      IF 3.2
    • Assignee Priority:
      P1

      Description

      The DataTable, since retiming these manipulations to occur after child update iteration in the UpdateModel phase of the lifecycle, can add events to be executed following.

      I would prefer recasting existing event types as "pre-filter", "pre-sort", "pre-page", and record this as an API deviation in the new version.

        Issue Links

          Activity

          Hide
          Nils Lundquist added a comment -

          This will involve some API changes, renaming the current sort event to presort, etc. So it will have to wait till 3.3.

          Show
          Nils Lundquist added a comment - This will involve some API changes, renaming the current sort event to presort, etc. So it will have to wait till 3.3.
          Hide
          Nils Lundquist added a comment -

          We've decided not to change the API as much as possible to makes these changes, however, some changes will be necessary because we currently have no means of defining two events at different times for the same ajax event type.

          This is an issue because filter is the only one of the ace:dataTable features with an attribute MethodExpression for a listener. All other events have listeners via ace:ajax. If they all add MethodExpressions it would be trivial to add more attributes to bind post-feature listeners.

          With ace:ajax the question is how to represent a post event listener, as a new event type? Or as a new attribute of ace:ajax? All ace:ajax events are currently executed at decode by design, which is fine for pre-feature events.

          For post-feature events, they should be executed as the last action of a component in UpdateModel or if possible immediately after the processing of a feature.

          Possible representations:

          <ace:dataTable>
              <ace:ajax event="page" listener="#{bean.prePageListener}"
                      execute="..." render="..."/>
              <ace:ajax event="page" listener="#{bean.postPageListener}"
                      execute="..." render="..." post="true"/>
              // Merges the execute and the render
          </ace:dataTable>
          

          Implementing the above however would require implementing a post-feature event call for each component or event.

          Show
          Nils Lundquist added a comment - We've decided not to change the API as much as possible to makes these changes, however, some changes will be necessary because we currently have no means of defining two events at different times for the same ajax event type. This is an issue because filter is the only one of the ace:dataTable features with an attribute MethodExpression for a listener. All other events have listeners via ace:ajax. If they all add MethodExpressions it would be trivial to add more attributes to bind post-feature listeners. With ace:ajax the question is how to represent a post event listener, as a new event type? Or as a new attribute of ace:ajax? All ace:ajax events are currently executed at decode by design, which is fine for pre-feature events. For post-feature events, they should be executed as the last action of a component in UpdateModel or if possible immediately after the processing of a feature. Possible representations: <ace:dataTable> <ace:ajax event= "page" listener= "#{bean.prePageListener}" execute= "..." render= "..." /> <ace:ajax event= "page" listener= "#{bean.postPageListener}" execute= "..." render= "..." post= " true " /> // Merges the execute and the render </ace:dataTable> Implementing the above however would require implementing a post-feature event call for each component or event.
          Hide
          Nils Lundquist added a comment - - edited

          Another issue is that all ace:ajax listeners are executed by design at the same time.

          Show
          Nils Lundquist added a comment - - edited Another issue is that all ace:ajax listeners are executed by design at the same time.
          Hide
          Nils Lundquist added a comment -

          The more I think about it the more sense it makes to just make these MethodExpression properties :/

          Show
          Nils Lundquist added a comment - The more I think about it the more sense it makes to just make these MethodExpression properties :/
          Hide
          Nils Lundquist added a comment -

          Well I've discovered that this effort has been misguided.

          The page, filter and sort listeners all became post-event after we moved the feature processing to updateModel (in ICE-8593). This means that listener behaviour changed in 3.2. Use of the immediate keyword currently allows pre-event listeners.

          The ace:ajax listeners were always running at invoke application, which just happened to be pre-event due to the execution point of sort/filter/page.

          However this work did at least uncover the missing portion of ICE-7751 that enables multiple ace:ajax tags for the same event type.

          Show
          Nils Lundquist added a comment - Well I've discovered that this effort has been misguided. The page, filter and sort listeners all became post-event after we moved the feature processing to updateModel (in ICE-8593). This means that listener behaviour changed in 3.2. Use of the immediate keyword currently allows pre-event listeners. The ace:ajax listeners were always running at invoke application, which just happened to be pre-event due to the execution point of sort/filter/page. However this work did at least uncover the missing portion of ICE-7751 that enables multiple ace:ajax tags for the same event type.

            People

            • Assignee:
              Nils Lundquist
              Reporter:
              Nils Lundquist
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: