You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Rafael Winterhalter (JIRA)" <ji...@apache.org> on 2012/09/19 12:07:18 UTC
[jira] [Created] (WICKET-4772) DataTable API
Rafael Winterhalter created WICKET-4772:
-------------------------------------------
Summary: DataTable API
Key: WICKET-4772
URL: https://issues.apache.org/jira/browse/WICKET-4772
Project: Wicket
Issue Type: Improvement
Components: wicket-extensions
Affects Versions: 1.5.8
Reporter: Rafael Winterhalter
Priority: Minor
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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4772) DataTable API
Posted by "Rafael Winterhalter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rafael Winterhalter updated WICKET-4772:
----------------------------------------
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.
was:
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.
> DataTable API
> -------------
>
> Key: WICKET-4772
> URL: https://issues.apache.org/jira/browse/WICKET-4772
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-extensions
> Affects Versions: 1.5.8
> Reporter: Rafael Winterhalter
> Priority: Minor
> Labels: AbstractToolbar, DataTable
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4772) DataTable API and handling of
AbstractToolbar
Posted by "Rafael Winterhalter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rafael Winterhalter updated WICKET-4772:
----------------------------------------
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.
was:
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
> DataTable API and handling of AbstractToolbar
> ---------------------------------------------
>
> Key: WICKET-4772
> URL: https://issues.apache.org/jira/browse/WICKET-4772
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-extensions
> Affects Versions: 1.5.8
> Reporter: Rafael Winterhalter
> Priority: Minor
> Labels: AbstractToolbar, DataTable
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4772) DataTable API
Posted by "Rafael Winterhalter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rafael Winterhalter updated WICKET-4772:
----------------------------------------
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.)
was:
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.
> DataTable API
> -------------
>
> Key: WICKET-4772
> URL: https://issues.apache.org/jira/browse/WICKET-4772
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-extensions
> Affects Versions: 1.5.8
> Reporter: Rafael Winterhalter
> Priority: Minor
> Labels: AbstractToolbar, DataTable
>
> 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.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4772) DataTable API and handling of
AbstractToolbar
Posted by "Rafael Winterhalter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rafael Winterhalter updated WICKET-4772:
----------------------------------------
Summary: DataTable API and handling of AbstractToolbar (was: DataTable API)
> DataTable API and handling of AbstractToolbar
> ---------------------------------------------
>
> Key: WICKET-4772
> URL: https://issues.apache.org/jira/browse/WICKET-4772
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-extensions
> Affects Versions: 1.5.8
> Reporter: Rafael Winterhalter
> Priority: Minor
> Labels: AbstractToolbar, DataTable
>
> 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
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4772) DataTable API
Posted by "Rafael Winterhalter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rafael Winterhalter updated WICKET-4772:
----------------------------------------
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
was:
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.)
> DataTable API
> -------------
>
> Key: WICKET-4772
> URL: https://issues.apache.org/jira/browse/WICKET-4772
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-extensions
> Affects Versions: 1.5.8
> Reporter: Rafael Winterhalter
> Priority: Minor
> Labels: AbstractToolbar, DataTable
>
> 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
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4772) DataTable API and handling of
AbstractToolbar
Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Grigorov resolved WICKET-4772.
-------------------------------------
Resolution: Fixed
Fix Version/s: 6.2.0
Assignee: Martin Grigorov
Getters for the main sub-parts are added with rev 76aef88.
Please attach a patch with any further improvements you may see.
> DataTable API and handling of AbstractToolbar
> ---------------------------------------------
>
> Key: WICKET-4772
> URL: https://issues.apache.org/jira/browse/WICKET-4772
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-extensions
> Affects Versions: 1.5.8
> Reporter: Rafael Winterhalter
> Assignee: Martin Grigorov
> Priority: Minor
> Labels: AbstractToolbar, DataTable
> Fix For: 6.2.0
>
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4772) DataTable API
Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458550#comment-13458550 ]
Martin Grigorov commented on WICKET-4772:
-----------------------------------------
Please attach a patch with your suggested changes.
Thanks!
> DataTable API
> -------------
>
> Key: WICKET-4772
> URL: https://issues.apache.org/jira/browse/WICKET-4772
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-extensions
> Affects Versions: 1.5.8
> Reporter: Rafael Winterhalter
> Priority: Minor
> Labels: AbstractToolbar, DataTable
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira