Hi all,
[X] Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.
[X] I might rethink upgrading if my choice doesn't win.
I didn't try wicket 1.4 yet, but I read questions and comments from
users in this list. My impression so far has been that there has been a
small design mistake in the way the current 1.4 implementation has been
done. I perceive that IModel<T> is conceptually correct as a Model can
be seen as a container of something (of type T). Writing
DropDownChoice<T> is a shortcut that does not seem conceptually correct
as in this case, the component is not a container of type T but a
container of type IModel<T>. So you should have something like
DropDownChoice<IModel<T>> (I know this not valid java). Generifying the
Page component is even worse as possibly a page can hold components with
different model types and not have a model type on its own. Also, wicket
is designed to allow some components not to have model on their own and
rely on the model stored in a parent component (very nice and powerful
feature).
Please note that using generic this way is already possible with wicket
1.3 if you define an interface that would be for instance IMyModel<T>
extends IModel. For instance, I have a generic model defined as
DetachableBeanModel<K,T> where K is the key type and T is the bean type.
This type is indeed a container of a key element and of a bean element.
I hope it helps,
Bernard.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
