Wicket
  1. Wicket
  2. WICKET-4535

Inconsistent use of generics in sorting APIs

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 6.0.0-beta1
    • Fix Version/s: 6.0.0-beta2
    • Component/s: wicket-extensions
    • Labels:
      None

      Description

      The Sort APIs use very generics inconsistently. Classes like SortableDataProvider, ISortState, SortParam etc do not all uniformly cater for sort properties other than string. There is a lot of unchecked casting, which is not really required, if generics were used across the board.

      Fixing this will probably cause API changes for 6.

      1. WICKET-4535-5.patch
        15 kB
        Jesse Long
      2. myproject.zip
        24 kB
        Jesse Long
      3. WICKET-4535-4.patch
        15 kB
        Jesse Long
      4. WICKET-4535-3.patch
        1 kB
        Jesse Long
      5. WICKET-4535-2.patch
        101 kB
        Jesse Long
      6. WICKET-4535-1.patch
        30 kB
        Jesse Long

        Activity

        Hide
        Jesse Long added a comment -

        Basically, it all boils down to ISortState being generic. So many things make assumptions about ISortState being ISortState<String>

        Show
        Jesse Long added a comment - Basically, it all boils down to ISortState being generic. So many things make assumptions about ISortState being ISortState<String>
        Hide
        Jesse Long added a comment -

        WICKET-4535-1.patch

        Initial work on adding generics for the Sort APIs. I have made all sort fields must extends Serializable, which makes sense to me.

        I have made ISortableDataProvider and ISortableTreeProvider implement ISortableStateLocator<String> (ie. String type sort properties by default). We must introduce a new type parameter to these classes to allow arbitrary sort fields. I would recommend it.

        I have not fxes HeadersToolbar and AjaxFallbackHeadersToolbar, but changing these requires IColumn to change as well, allowing IColumn to return the generic sort property type in getSortProperty(). I would actually recommend these changes, but it should probably be debated first.

        Show
        Jesse Long added a comment - WICKET-4535 -1.patch Initial work on adding generics for the Sort APIs. I have made all sort fields must extends Serializable, which makes sense to me. I have made ISortableDataProvider and ISortableTreeProvider implement ISortableStateLocator<String> (ie. String type sort properties by default). We must introduce a new type parameter to these classes to allow arbitrary sort fields. I would recommend it. I have not fxes HeadersToolbar and AjaxFallbackHeadersToolbar, but changing these requires IColumn to change as well, allowing IColumn to return the generic sort property type in getSortProperty(). I would actually recommend these changes, but it should probably be debated first.
        Hide
        Jesse Long added a comment -

        WICKET-4535-2.patch

        New patch, may have some improvements on the first patch.

        Also contains changes to SortableDataProvider and friends to take type parameter for sort property. This requires changes to DataTable TableTree etc, which I have implemented (Adding type parameter for sort property). Also touched IColumn.

        I have left the DefaultDataTable, and the tree equivalent as having the sort property type of String (default implementation does not have so many API changes and type params).

        I have updated wicket-devutils and wicket-examples for the changes.

        I have tried to add @Override to all methods needing it in all files I have touched. (That's why there are so many changes just adding @Override).

        In wicket-examples, I added generics where they were missing for that parts of the code I touched, and the classes those parts used.

        I removed Removed SortableTreeProvider#setSortState() see https://issues.apache.org/jira/browse/WICKET-3580 basically, it does not make sense to modify the sort state itself, because the data/tree provider is coded to use just one type of ISortState it knows about. In fact, that implementation failed is the ISortState was not SingleSortState, and SingleSortState is mutable, so there is no need to set it.

        This is obviously not a small patch, and it introduces a lot of API changes. I'm sure a lot of people will complain about the introduction of second type parameters for many of the types. That's why I left the DefaultDataTable etc as DataTable<T, String>.

        I dont think we can go middle road on this one. We must either implement the generics correctly (as I hope I have done with this patch), or remove the type parameter from ISortState, and just use String.

        ISortState is either parameterizable, or it isn't. We must make that decision. If it is to be parameterizable, then I think this patch is needed. If not, then we must remove the half implemented parameterization for ISortState and all its uses.

        Show
        Jesse Long added a comment - WICKET-4535 -2.patch New patch, may have some improvements on the first patch. Also contains changes to SortableDataProvider and friends to take type parameter for sort property. This requires changes to DataTable TableTree etc, which I have implemented (Adding type parameter for sort property). Also touched IColumn. I have left the DefaultDataTable, and the tree equivalent as having the sort property type of String (default implementation does not have so many API changes and type params). I have updated wicket-devutils and wicket-examples for the changes. I have tried to add @Override to all methods needing it in all files I have touched. (That's why there are so many changes just adding @Override). In wicket-examples, I added generics where they were missing for that parts of the code I touched, and the classes those parts used. I removed Removed SortableTreeProvider#setSortState() see https://issues.apache.org/jira/browse/WICKET-3580 basically, it does not make sense to modify the sort state itself, because the data/tree provider is coded to use just one type of ISortState it knows about. In fact, that implementation failed is the ISortState was not SingleSortState, and SingleSortState is mutable, so there is no need to set it. This is obviously not a small patch, and it introduces a lot of API changes. I'm sure a lot of people will complain about the introduction of second type parameters for many of the types. That's why I left the DefaultDataTable etc as DataTable<T, String>. I dont think we can go middle road on this one. We must either implement the generics correctly (as I hope I have done with this patch), or remove the type parameter from ISortState, and just use String. ISortState is either parameterizable, or it isn't. We must make that decision. If it is to be parameterizable, then I think this patch is needed. If not, then we must remove the half implemented parameterization for ISortState and all its uses.
        Hide
        Jesse Long added a comment -

        Smaller patch just removing the type parameters to ISortState and friends. This is probably the easiest and most sensible way for wicket 6.

        Show
        Jesse Long added a comment - Smaller patch just removing the type parameters to ISortState and friends. This is probably the easiest and most sensible way for wicket 6.
        Hide
        Jesse Long added a comment -

        Apparently git diff works a whole lot better than git status for generating patches

        Show
        Jesse Long added a comment - Apparently git diff works a whole lot better than git status for generating patches
        Hide
        Jesse Long added a comment -

        The problem is not yet solved. OrderByLink still makes assumptions about ISortState<String>.

        Please see attached quickstart. This is a simple inplementation of ISortableDataProvider using integers to sort arrays of strings by index. Throws cast exception every time.

        Show
        Jesse Long added a comment - The problem is not yet solved. OrderByLink still makes assumptions about ISortState<String>. Please see attached quickstart. This is a simple inplementation of ISortableDataProvider using integers to sort arrays of strings by index. Throws cast exception every time.
        Hide
        Jesse Long added a comment -

        WICKET-4535-5.patch

        This fixes my issue for 6.0.0-beta2. Also included some javadoc fixes.

        Also added version for archetype extension in quickstart pom. I cant build wicket without that... maven 3.0.3

        Show
        Jesse Long added a comment - WICKET-4535 -5.patch This fixes my issue for 6.0.0-beta2. Also included some javadoc fixes. Also added version for archetype extension in quickstart pom. I cant build wicket without that... maven 3.0.3
        Hide
        Martin Grigorov added a comment -

        The CssProvider deals with the value of the CSS class, so it could be only a String, I think.
        I'll try your quickstart to see why it fails with ClassCastException.

        Show
        Martin Grigorov added a comment - The CssProvider deals with the value of the CSS class, so it could be only a String, I think. I'll try your quickstart to see why it fails with ClassCastException.
        Hide
        Martin Grigorov added a comment -

        Patch WICKET-4535-5.patch is applied. Thanks!

        Show
        Martin Grigorov added a comment - Patch WICKET-4535 -5.patch is applied. Thanks!
        Hide
        Betlista added a comment -

        Just wondering is there a real-life example in which to use something else than String? There was example (if I understood it well) with int as index...

        Let say I have object O with array arr and I want to sort by second element in that array. I'd simply use property arr[1] and I'm done, or I missed something?

        Show
        Betlista added a comment - Just wondering is there a real-life example in which to use something else than String? There was example (if I understood it well) with int as index... Let say I have object O with array arr and I want to sort by second element in that array. I'd simply use property arr [1] and I'm done, or I missed something?
        Hide
        Jesse Long added a comment -

        Hi Betlista,

        Originally, I was actually in favor of just standardizing on Strings, but now that sort parameters are part of Wicket, I make heavy use of them.

        This is how I use it: I have Field<R, T> objects. These objects describe a field that is either in a table of type R, or reachable from a R record via joins. Each sortable column returns a Field<R, T> as sort property. My ISortableDataProvider is a ISortableDataProvider<R, Field<R, T>> and returns R records representing a row in the R table. Each column then uses its Field object to retrieve and render the data for that column from the R record - the type of the data in the column is T. When sorting, the the ISortableDataProvider is given the Field object for the column selected, and it uses that to generate the correct SQL joins and "ORDER BY" phrase. All my paging, filtering and ordering is done by the database. IDataProvider#size() is implemented as a "SELECT COUNT ..." query.

        Show
        Jesse Long added a comment - Hi Betlista, Originally, I was actually in favor of just standardizing on Strings, but now that sort parameters are part of Wicket, I make heavy use of them. This is how I use it: I have Field<R, T> objects. These objects describe a field that is either in a table of type R, or reachable from a R record via joins. Each sortable column returns a Field<R, T> as sort property. My ISortableDataProvider is a ISortableDataProvider<R, Field<R, T>> and returns R records representing a row in the R table. Each column then uses its Field object to retrieve and render the data for that column from the R record - the type of the data in the column is T. When sorting, the the ISortableDataProvider is given the Field object for the column selected, and it uses that to generate the correct SQL joins and "ORDER BY" phrase. All my paging, filtering and ordering is done by the database. IDataProvider#size() is implemented as a "SELECT COUNT ..." query.
        Hide
        Betlista added a comment - - edited

        I'll have to check your patches precisely. Your usage seems valid to me. I got here, because I reported WICKET-5348 where IColumn changed from IColumn<T> to IColumn<T, S> and it seems to me (according to your description), that T = S. It seems to me, that while I want DataTable<ROW> - getColumns() returns list of IColumn<ROW, COLUMN> while it should be IColumn<COLUMN> principially.

        Now, when I checked Wicket sources I found I got confused with parameter misuse in IColumn (PropertyColumn) and PropertyModel - in IColumn<T> (old version) T is type of row, while in PropertyModel<T> T is type of "column".

        Show
        Betlista added a comment - - edited I'll have to check your patches precisely. Your usage seems valid to me. I got here, because I reported WICKET-5348 where IColumn changed from IColumn<T> to IColumn<T, S> and it seems to me (according to your description), that T = S. It seems to me, that while I want DataTable<ROW> - getColumns() returns list of IColumn<ROW, COLUMN> while it should be IColumn<COLUMN> principially. Now, when I checked Wicket sources I found I got confused with parameter misuse in IColumn (PropertyColumn) and PropertyModel - in IColumn<T> (old version) T is type of row, while in PropertyModel<T> T is type of "column".

          People

          • Assignee:
            Martin Grigorov
            Reporter:
            Jesse Long
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development