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]
