Tomahawk's t:dataTable requires SortableDataModel, which is why that
check is in here. At some point I'd love to see that requirement
relaxed, but no one has done further work toward that end.
I think the easiest thing to do right now is to subclass HtmlDataTable
and override createDataModel.
That's a very good idea. However, in the latest svn sources the HtmlDataTable
component still uses SortableModel class to set the current sort column.
Wouldn't be normal to use BaseSortableModel class to allow extensibility?
Thanks.
Mike Kienenberger wrote:
As a first step in this process,
It was left that way to provide identical backward compatible behavior.
However, you should be able to subclass (or use) BaseSortableModel
instead of the default sortable model.
On 11/27/07, CatalinPetrisor [EMAIL PROTECTED] wrote:
That's a very good idea. However, in the latest svn sources
I can subclass it of course, but because HtmlDataTable (in createDataModel
method) checks if the DataModel is an instance of SortableDataModel, it will
actually wrap my extended BaseSortableModel into a SortableModel, that will
not use my custom defined comparator.
I would expect that
As a first step in this process, I've separated SortableDataModel into
SortableDataModel (current behavior, final, subclass of
BaseSortableDataModel) and BaseSortableDataModel (extendable, works on
Comparators).
I tested all of the simple examples involving dataTable at one point,
but it's
If you're trying to say that the current sorting code is a bit odd,
I'd agree :-)
I think it needs to be rethought and rewritten.
Some of the things I suspect:
- You cannot have a sorted display without creating user-clickable
sortable headers.
- You cannot specify a list of sort criteria, even
I took a look at SortableModel and t:dataTable sorting again last
night. My requirements in most cases are to simply specify a sort
order in the page code, not to allow end-users to manipulate the sort
order.From what I can tell, there's no easy way to do this. I
documented the most
