Point!--but i thought it is intended to extract a survey kind of info(with explanation if one has one) Just that the information here is overflowing with untraceable debates
On Tue, Jun 3, 2008 at 12:47 AM, Bernard Niset <[EMAIL PROTECTED]> wrote: > Hi Atul, > Please read again the initial post from Eelco. He explicitly wrote: "Note > that it is not a vote; we only want to get an idea of what you think." and > further away: "Thanks in advance for everyone participating, and pls feel > free to explain yourself further beyond just answering these questions!". > Bernard. > > atul singh a écrit : > > 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] >>> >>> >>> >>> >> >> >> >
