Hello everyone, I feel bad that a vote thread has been converted to one of discussion... At this moment wicket is *for *creating custom components. If these custom component writing gets complicated we will not be able to appreciate wicket as much(as much as we do now).Generics will complicate the *extend* at the moment for new user...I feel(after reading through everything). In core-java , fewer classes aim for extension by user. They rather are end product to be used, to be composed of.
The best way still for wicket is *to implement generics partially *and* then start incorporating into OUT-OF-BOX(components less prone to extension) later on in further releases. The fact is that less people can make to wicket core-development team, and then who will maintain the bloat(meaning undesired syntactical features). Who will release non-generics versions for freshers. In Design Patterns I learnt about the open-closed principle. Closed for change and open for extension. Generics forces us to see into a new design pattern---Generify the the most closed only, based on use cases--If there is more of a need of extension of classes by end user AND there is flexibility while extending(wicket is one case which is flexible when you extend)--then wait, do not generify. * On Mon, Jun 2, 2008 at 11:03 PM, Bernard Niset <[EMAIL PROTECTED]> wrote: > 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] > >
