All,
I have created a JIRA issue and attach a patch which implements the
API change with respect to collections and generics as I have proposed
it. This doesn't just cover ListView and DropDownChoice. As I
started working on it, the more and more "stuff" I had to change so
that the API was consistent. All of the core "choice" classes (things
that extend AbstractChoice) are affected and so is Palette. As I've
said in other posts, I did not change any test or example code in this
patch and everything works just fine. Also, the only code that would
be affected by this change would be any case where someone is trying
to modify the "choices" collection of a choice component through the
component itself (through getChoices() or through the default model)
rather than maintaining a reference to the original list:
DropDownChoice<String> ddc = ...;
ddc.getChoices().add("Hello, World!");
The work-around here is to just simply cast the collection. However,
this type of situation seems to be somewhat limited (in my experience
at least). Also, we have to remember, the 1.4 releases are not final
releases (yet) and we're trying to get the API "right." The headache
of having to fix this relatively rare, easy-to-fix situation for those
bleeding-edgers (such as myself) at this point is an acceptable
growing pain, IMHO. I've had worse growing pains throughout this 1.4
lifecycle, such as the whole "default model" thing. It would be much
harder to "fix" this after the final 1.4 releases come out, because
then you *do* have to worry about backward compatibility. The good
thing about this proposed API is that it takes the generics "thinking"
out of the picture when you're dealing with generics in Wicket. The
API will just handle anything you can throw at it.
One other concern folks have when they see a constructor signature like this:
public DropDownChoice(String id, IModel<T> model, IModel<? extends
List<? extends T>> choices)
is that they're going to have to do something like this in their code:
IModel<T> model = ...;
IModel<? extends List<? extends T>> choicesModel = ...;
DropDownChoice<T> myDdc = new DropDownChoice("ddc", model, choicesModel);
That's just not true. This would work just fine (and does in the
test/example code):
IModel<T> model = ...;
IModel<List<T>> choicesModel = ...;
DropDownChoice<T> myDdc = new DropDownChoice("ddc", model, choicesModel);
Another concern is with the fact that we have two different types of
generics showing up in the same constructor, one that accepts "T" and
another that accepts anything that extends "T." This is perfectly
okay! If you have a DropDownChoice that edits a property of type
Employee, you could fill the DropDownChoice with a list of Manager
objects (assuming Managers *are* Employees, in that Manager extends
Employee).
What I'm trying to do is take the headaches away from the "users" and
push it into the framework code (it's really not that bad of a
headache). Developing generics-enabled "frameworks" isn't the easiest
thing to do, especially if you want to get it right. The goal should
be to make it so that the generics don't get in the way of the user of
the framework and makes their work easier.
Thanks,
James
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
