Wicket
  1. Wicket
  2. WICKET-4772

DataTable API and handling of AbstractToolbar

    Details

      Description

      The DataTable API is not optimal from my point of view as a user. What I do today is that I copy-paste most of the data table code in order to break the data table API open. To name a tangible example:

      I implemented a toolbar that applies an Ajax-table-refreshing-filter to each column's values. The updating of the data table's contents is fairly simple by overriding the data table's "newBodyContainer" method, extracting the component and adding it to the AjaxRequestTarget whenever the table is updated. However, this does not affect any of the other abstract toolbars since they are of course not part of the body container. (Adding the entire table to the AjaxRequestTarget what would include the toolbars is not an option, however. This would also refresh the Ajax-filtering-toolbar itself and the e.g. filtering text field would loose its focus.)

      It could now be as easy as overriding the "addTopToolbar" and "addBottomToolbar" methods of the DataTable class and adding all toolbars that one extracted from calls to those methods but the filtering toolbar itself. This is however not possible since these components are not anchored in HTML-tags but in Wicket-tags.

      My suggestion:
      -> Refactor DataTable to allow access to all children by default. (Toolbars and body container).
      -> Refactor AbstractToolbars integration to allow adding to an AjaxRequestTarget

      This would allow for a whole bunch of new AjaxComponents that do not even need to reload the entire table. Since DataTables often operate with data base access, I belive this would be useful to many users.

        Activity

        Rafael Winterhalter created issue -
        Rafael Winterhalter made changes -
        Field Original Value New Value
        Description The DataTable API is not optimal from my point of view as its user. What I do today is that I copy-pasted most of the code in order to break the data table open a little bit since the original API does not allow me to.
        To name a tangible example:

        It is impossible to update a DataTable's toolbars by Ajax dynamically since the DataView does not allow for it, i.e. adding a toolbar which has its markup ID set to true to an AjaxRequestTarget throws me an exception.

        This makes it impossible to add another toolbar which must not lose its keyboard focus, in my case this is a filtering toolbar that rerenders the data table's content (which works by overriding the DataTables makeBodyContainer method and extracting the then created component) and all other (!) toolbars (which could work by overriding the addTopToolbar and addBottomToolbar methods and refreshing all toolbars but the one requesting the rerendering).

        I suggest a rather simple refactorization: Make all child components of the DataTable accessible by accessor methods. By doing so, the data table can be used way more flexible.
        The DataTable API is not optimal from my point of view as its user. What I do today is that I copy-pasted most of the code in order to break the data table open a little bit since the original API does not allow me to.
        To name a tangible example:

        It is impossible to update a DataTable's toolbars by Ajax dynamically since the DataView does not allow for it, i.e. adding a toolbar which has its markup ID set to true to an AjaxRequestTarget throws me an exception.

        This makes it impossible to add another toolbar which must not lose its keyboard focus, in my case this is a filtering toolbar that rerenders the data table's content (which works by overriding the DataTables makeBodyContainer method and extracting the then created component) and all other (!) toolbars (which could work by overriding the addTopToolbar and addBottomToolbar methods and refreshing all toolbars but the one requesting the rerendering).

        I suggest a rather simple refactorization: Make all child components of the DataTable accessible by accessor methods. By doing so, the data table can be used way more flexible. Also, the AbstractToolbar should ensure that it is wrapped in a tr/td tag which can be added to an AjaxRequestTarget.
        Rafael Winterhalter made changes -
        Description The DataTable API is not optimal from my point of view as its user. What I do today is that I copy-pasted most of the code in order to break the data table open a little bit since the original API does not allow me to.
        To name a tangible example:

        It is impossible to update a DataTable's toolbars by Ajax dynamically since the DataView does not allow for it, i.e. adding a toolbar which has its markup ID set to true to an AjaxRequestTarget throws me an exception.

        This makes it impossible to add another toolbar which must not lose its keyboard focus, in my case this is a filtering toolbar that rerenders the data table's content (which works by overriding the DataTables makeBodyContainer method and extracting the then created component) and all other (!) toolbars (which could work by overriding the addTopToolbar and addBottomToolbar methods and refreshing all toolbars but the one requesting the rerendering).

        I suggest a rather simple refactorization: Make all child components of the DataTable accessible by accessor methods. By doing so, the data table can be used way more flexible. Also, the AbstractToolbar should ensure that it is wrapped in a tr/td tag which can be added to an AjaxRequestTarget.
        The DataTable API is not optimal from my point of view as its user. What I do today is that I copy-pasted most of the code in order to break the data table open a little bit since the original API does not allow me to.
        To name a tangible example:

        It is impossible to update a DataTable's toolbars by Ajax dynamically since the DataView does not allow for it, i.e. adding a toolbar which has its markup ID set to true to an AjaxRequestTarget throws me an exception.

        This makes it impossible to add another toolbar which must not lose its keyboard focus, in my case this is a filtering toolbar that rerenders the data table's content (which works by overriding the DataTables makeBodyContainer method and extracting the then created component) and all other (!) toolbars (which could work by overriding the addTopToolbar and addBottomToolbar methods and refreshing all toolbars but the one requesting the rerendering).

        I suggest a rather simple refactorization: Make all child components of the DataTable accessible by accessor methods. By doing so, the data table can be used way more flexible. Also, the AbstractToolbar should ensure that it is wrapped in a tr/td tag which can be added to an AjaxRequestTarget, e.g. by determining the tr tag alrady inside of the DataTable HTML file and adding the AbstractToolbar directly to it. (I know this might mess up user created toolbars but on the other hand, this allows for a whole new set of Ajax-driven toolbars.)
        Rafael Winterhalter made changes -
        Description The DataTable API is not optimal from my point of view as its user. What I do today is that I copy-pasted most of the code in order to break the data table open a little bit since the original API does not allow me to.
        To name a tangible example:

        It is impossible to update a DataTable's toolbars by Ajax dynamically since the DataView does not allow for it, i.e. adding a toolbar which has its markup ID set to true to an AjaxRequestTarget throws me an exception.

        This makes it impossible to add another toolbar which must not lose its keyboard focus, in my case this is a filtering toolbar that rerenders the data table's content (which works by overriding the DataTables makeBodyContainer method and extracting the then created component) and all other (!) toolbars (which could work by overriding the addTopToolbar and addBottomToolbar methods and refreshing all toolbars but the one requesting the rerendering).

        I suggest a rather simple refactorization: Make all child components of the DataTable accessible by accessor methods. By doing so, the data table can be used way more flexible. Also, the AbstractToolbar should ensure that it is wrapped in a tr/td tag which can be added to an AjaxRequestTarget, e.g. by determining the tr tag alrady inside of the DataTable HTML file and adding the AbstractToolbar directly to it. (I know this might mess up user created toolbars but on the other hand, this allows for a whole new set of Ajax-driven toolbars.)
        The DataTable API is not optimal from my point of view as a user. What I do today is that I copy-paste most of the data table code in order to break the data table API open. To name a tangible example:

        I implemented a toolbar that applies a filter to each column's values. The updating of the data table's contents is fairly simple by overriding the data table's "newBodyContainer" method, extracting the component and adding it to the AjaxRequestTarget whenever the table is updated. However, this does not affect any of the other
        Rafael Winterhalter made changes -
        Summary DataTable API DataTable API and handling of AbstractToolbar
        Rafael Winterhalter made changes -
        Description The DataTable API is not optimal from my point of view as a user. What I do today is that I copy-paste most of the data table code in order to break the data table API open. To name a tangible example:

        I implemented a toolbar that applies a filter to each column's values. The updating of the data table's contents is fairly simple by overriding the data table's "newBodyContainer" method, extracting the component and adding it to the AjaxRequestTarget whenever the table is updated. However, this does not affect any of the other
        The DataTable API is not optimal from my point of view as a user. What I do today is that I copy-paste most of the data table code in order to break the data table API open. To name a tangible example:

        I implemented a toolbar that applies an Ajax-table-refreshing-filter to each column's values. The updating of the data table's contents is fairly simple by overriding the data table's "newBodyContainer" method, extracting the component and adding it to the AjaxRequestTarget whenever the table is updated. However, this does not affect any of the other abstract toolbars since they are of course not part of the body container. (Adding the entire table to the AjaxRequestTarget what would include the toolbars is not an option, however. This would also refresh the Ajax-filtering-toolbar itself and the e.g. filtering text field would loose its focus.)

        It could now be as easy as overriding the "addTopToolbar" and "addBottomToolbar" methods of the DataTable class and adding all toolbars that one extracted from calls to those methods but the filtering toolbar itself. This is however not possible since these components are not anchored in HTML-tags but in Wicket-tags.

        My suggestion:
        -> Refactor DataTable to allow access to all children by default. (Toolbars and body container).
        -> Refactor AbstractToolbars integration to allow adding to an AjaxRequestTarget

        This would allow for a whole bunch of new AjaxComponents that do not even need to reload the entire table. Since DataTables often operate with data base access, I belive this would be useful to many users.
        Martin Grigorov made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Assignee Martin Grigorov [ mgrigorov ]
        Fix Version/s 6.2.0 [ 12323295 ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            Martin Grigorov
            Reporter:
            Rafael Winterhalter
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development