Re: users, please give us your opinion: what is your take on generics with Wicket

> 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 <bn@...> 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: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>    
>
>