You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Igor Vaynberg (JIRA)" <ji...@apache.org> on 2009/04/24 10:54:30 UTC
[jira] Resolved: (WICKET-2165) Improve the API's Consistency and
Flexibility With Respect to Generics and Collections
[ https://issues.apache.org/jira/browse/WICKET-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg resolved WICKET-2165.
-----------------------------------
Resolution: Fixed
Fix Version/s: 1.4-RC3
Assignee: Igor Vaynberg
> 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
> Assignee: Igor Vaynberg
> Fix For: 1.4-RC3
>
> 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.