[jira] Updated: (WICKET-2165) Improve the API's Consistency and Flexibility With Respect to Generics and Collections

["James Carman (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Carman updated WICKET-2165:
---------------------------------

    Attachment: WICKET-2165.patch

Here's my first crack at the proposed API changes.  Note that no unit test code had to be changed, so this appears to not "break" the API at all.  The potential API break is where a user tries to modify the List<? extends T> model object.  However, that appears to be an obscure usecase.

> Improve the API's Consistency and Flexibility With Respect to Generics and Collections
> --------------------------------------------------------------------------------------
>
>                 Key: WICKET-2165
>                 URL: https://issues.apache.org/jira/browse/WICKET-2165
>             Project: Wicket
>          Issue Type: Improvement
>          Components: wicket, wicket-extensions
>    Affects Versions: 1.4-RC2
>            Reporter: James Carman
>         Attachments: WICKET-2165.patch
>
>
> There have been discussions about how collections are treated inconsistently in the Wicket API.  For example, DropDownChoice allows a model of type IModel<List<? extends T>> and ListView only allows a model of type IModel<List<T>>.  The most flexible approach for these situations (for the client code) is to allow IModel<? extends List<? extends T>>.  However, merely synchronizing these two particular classes would leave other parts of the API inconsistent (Palette, ListChoice, ListMultipleChoice, etc.).  What we need is a consistent approach to this situation across the entire API so that the API is more cohesive and understandable (if the user sees this weird syntax once they'll understand it everywhere).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.