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

[Stefan Lindner]

Brill Pappin wrote
>I don't know, I think the discussion is going *toward* generics.
>Frankly I can't even see why its an issue at all, the language has
evolved and uses them... Why would Wicket not also use them its inline
with >the current state of the language?
>
>There is no reason that people who can't get their heads around
Generics can't use the older releases that don't include it, but IMO any
java >developer who doesn't get generics yet better make some time to
learn, because like it or not, they *will* be dealing with them.

I agree totally with you. My expericence with Generics over the last two
years was that any project that was adopted to generics had much less
errors afterwards.

But the main problem in this discussion seems to be that there are two
very different sorts of Web Applications that are developed with wicket
and both may have predecessors that are non generic.

Type A: A Web applicatons that make heavy use of Models, like classic
desktop allications that are ported to the web. I think the programmers
of such applications like Generics becaus they help them to avoid erros
and the current wicket generic implementation leads to a strong typed
application that needs a good object model (and a good database design).
If you port an exisitng wicket application with no generic to wicket 1.4
you might discover some unclear object model problems in your exisitng
code. And it's always easier to point to wicket's generics than to blame
your own code :-)

Type B: A Web Application with more static content, only some date (like
user logins, user profile data). In this case it's clear that some
people say "why should I always tyle 'Link<Void>', none of my links has
a Model, just about 10% of my Components have a Model". But why dont't
they write their own wrapper e.g. MyVoidLink extends Link<Void>? I
remember a dicsusson about such Components some weeks ago.


What do you think about it? Would it help users of Type B to have
VoidComponents?

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[jwcarman]

On Mon, Jun 2, 2008 at 12:11 PM, Sebastiaan van Erk <sebster@...> wrote:
> A raw type is a parameterized type in which the type parameters are not
> filled in, i.e., new HashMap() (instead of new HashMap<String, Integer>()).
>
> Just try to return one of your old (non-generified) HomePage.class classes
> (i.e., HomePage extends WebPage instead of HomePage extends WebPage<Void>)
> in your WebApplication's getHomePage() method, and you will see that it does
> not compile.

There is a section on the wiki addressing this now.  I would propose
that whenever referring to "class objects that represent Page
subclasses" we use Class<? extends Page> rather than Class<? extends
Page<?>>.  This allows us to specify that it has to be a page class,
but it doesn't make the page class have to be generified.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Alastair Maw-3]

On Mon, Jun 2, 2008 at 3:54 PM, Martin Funk <mafulafunk@...>
wrote:

> There are quite some methods that don't return the component,
> but its class. Maybe most prominently 'getHomePage()' in Application.
>
> This used to have the signature:
> public abstract Class getHomePage();
>
> And a popular implementation would be:
> public Class getHomePage() {
>   return HomePage.class
> }
>
> So maybe in favor of that popular implementation its current signature is:
>
> Application: public abstract Class<? extends Page<?>> getHomePage();
>
> which is not a generic method but a method with a generified return
> parameter.
> But at least this works with the existing user code basis very well.
> But it also implies a circle I can't break up in my mind yet.
> This signature forces you to implement HomePage as a raw type, a class
> without type parameters, esp. not generic.
> Though on the other hand HomePage is a descendant of Component which is
> generic, of course.
> Which is a strong sign for HomePage to be generic too.
>
> I think both ends don't go together well.
>
> How is this going to be solved? Or, explained?

<shrug>
One could generify Application. ;-)

class Application<P extends Page> {
   public abstract P getHomePage();
}

Generifying Component buys you no casting, at the expense of being hideously
verbose at times.
Generifying IModel buys you more obvious method signatures, particularly for
things like DropDownChoice.

The second is almost certainly worth doing. That said, I use PropertyModel
more often than anything else, and that doesn't allow you to make any
guarantees anyway. :-/

Al

[whoover]

Wouldn't that infer that the component has to have generics, or am I
missing something here?

Something like...

public abstract class Component<M extends IModel<T>, T> implements
IClusterable, IConverterLocator {
        ...
        public final M getModel(){
                ...
        }
        ...
        public final T getModelObject(){
                ...
        }
        ...
}

-----Original Message-----
From: Jan Kriesten [mailto:jan.kriesten@...]
Sent: Monday, June 02, 2008 12:03 PM
To: users@...
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket


Hi Sebastian,

> What about getModel()? If componennt is not generified I'm really
> wondering if the there is any benefit to generics at all... (I do
> really think it will spawn lots of questions on the list as well).

what's the problem with getModel? If you specialize on a certain
Component, you can implement T getModel() ?

Regards, --- Jan.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Sebastiaan van Erk]

You could use Java's covariant return types to override getModel() to
return a specific type. Which would mean that you would need to subclass
to "simulate" generics (with a new subclass for each type). Also, when
using anonymous subclasses it becomes rather pointless and you'd be back
to casting.

Regards,
Sebastiaan

Hoover, William wrote:

> Wouldn't that infer that the component has to have generics, or am I
> missing something here?
>
> Something like...
>
> public abstract class Component<M extends IModel<T>, T> implements
> IClusterable, IConverterLocator {
> ...
> public final M getModel(){
> ...
> }
> ...
> public final T getModelObject(){
> ...
> }
> ...
> }
>
> -----Original Message-----
> From: Jan Kriesten [mailto:jan.kriesten@...]
> Sent: Monday, June 02, 2008 12:03 PM
> To: users@...
> Subject: Re: users, please give us your opinion: what is your take on
> generics with Wicket
>
>
> Hi Sebastian,
>
>> What about getModel()? If componennt is not generified I'm really
>> wondering if the there is any benefit to generics at all... (I do
>> really think it will spawn lots of questions on the list as well).
>
> what's the problem with getModel? If you specialize on a certain
> Component, you can implement T getModel() ?
>
> Regards, --- Jan.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

[Jan Kriesten]

hi william,

> Wouldn't that infer that the component has to have generics, or am I
> missing something here?

you miss something...

getModel/getModelObject would have to be non-final and overriden by the
specialized component (return types are covariant, so you can override object
with something more specific).

regards, --- jan.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jan Kriesten]

hi al,

> The second is almost certainly worth doing. That said, I use PropertyModel
> more often than anything else, and that doesn't allow you to make any
> guarantees anyway. :-/

good point. :-)

regards, --- jan.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[whoover]

Enlighten me with an example

-----Original Message-----
From: Jan Kriesten [mailto:jan.kriesten@...]
Sent: Monday, June 02, 2008 12:23 PM
To: users@...
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket


hi william,

> Wouldn't that infer that the component has to have generics, or am I
> missing something here?

you miss something...

getModel/getModelObject would have to be non-final and overriden by the
specialized component (return types are covariant, so you can override
object with something more specific).

regards, --- jan.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jan Kriesten]

hi sebastiaan,

> You could use Java's covariant return types to override getModel() to
> return a specific type. Which would mean that you would need to subclass
> to "simulate" generics (with a new subclass for each type).

not really, you can do generify your components from a certain level and
wouldn't have to subclass for each type. that way you could require
formcomponents to have generics on them, without the whole component tree
generified.

but i guess this would also lead to many questions why this and not that...

i'd prefer living with have to cast when it comes to getModel/getModelObject...

regards, --- jan.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jan Kriesten]

hi william,

> Enlighten me with an example

just like that:

Component { public object getModelObject(){ ... } }
FormComponent<T> extends Component { public T getModelObject() { ... } }

regards, --- jan.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Eelco Hillenius]

On Mon, Jun 2, 2008 at 7:45 AM, Matej Knopp <matej.knopp@...> wrote:
> I'm not sure I like where this discussion is going. I don't see anyone
> having any particular objections against current state. I think before
> we even think of (partially) reverting generics we have to discuss
> what's wrong (except the verbosity of course, but that's not something
> we can really do about) with current state. I use wicket with generics
> daily and I don't see any particular show stopper so far.

I just want to get a hunch of what people are thinking at the moment.
It's not meant to be a discussion thread, nor a decision thread.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[whoover]

Then we are on the same page with one thing... some level in the
component hierarchy would have to be generic.

Your original example specified "T getModel()" - you must have meant "T
getModelObject()" ;o)

-----Original Message-----
From: Jan Kriesten [mailto:jan.kriesten@...]
Sent: Monday, June 02, 2008 12:34 PM
To: users@...
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket


hi william,

> Enlighten me with an example

just like that:

Component { public object getModelObject(){ ... } } FormComponent<T>
extends Component { public T getModelObject() { ... } }

regards, --- jan.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Eelco Hillenius]

> IMHO storing a model in a Component is more a convenience than a
> fundamental part of component-ness. This may be part of the reason that
> genericizing Component is so contentious.

I agree.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Sebastiaan van Erk]

Yes, property model (and compound friends) don't mix well with generics.
With generics a type safe alternative is wanted (and a very good start
is Matej and Johan's type-safe model implementation).

Regards,
Sebastiaan

Jan Kriesten wrote:

>
> hi al,
>
>> The second is almost certainly worth doing. That said, I use
>> PropertyModel
>> more often than anything else, and that doesn't allow you to make any
>> guarantees anyway. :-/
>
> good point. :-)
>
> regards, --- jan.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

[Eelco Hillenius]

> Question is, how many of those users actually use generified wicket on
> day-to-day basis.

Common, a quick glance and comparing some of the code/ examples you
see with the code you write now (with 1.2/ 1.3) is enough to get a
good - and as far as I am concerned informed well enough - idea.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Matej Knopp]

You really have to use it to appreciate the benefits. Quick glance
will just be scary :)

-Matej

On Mon, Jun 2, 2008 at 6:45 PM, Eelco Hillenius
<eelco.hillenius@...> wrote:

>> Question is, how many of those users actually use generified wicket on
>> day-to-day basis.
>
> Common, a quick glance and comparing some of the code/ examples you
> see with the code you write now (with 1.2/ 1.3) is enough to get a
> good - and as far as I am concerned informed well enough - idea.
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Charlie Dobbie]

On Sun, Jun 1, 2008 at 9:44 PM, Eelco Hillenius
<eelco.hillenius@...> wrote:

> 1) Generifying* Wicket
>   [X] Can best be done like currently in the 1.4 branch, where models
> and components are both generified. I care most about the improved
> static type checking generified models and components give Wicket.
>   [half-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.
>   [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill
> in your opinion here).
>   [ ] .... (anything other than these choices?)

I see the stronger-typing made possible with Generics as a step
forward for Java and for Wicket.  I believe that Generics will improve
my code, and make my life easier.  I understand that actually
implementing the Generified objects is harder than using them, and
that this task rests mostly on the devs' shoulders!


> 2) How strongly do you feel about your choice above?
>   [X] Whatever choice ultimately made, I'll happily convert/ start
> using 1.4 and up.
>   [ ] I might rethink upgrading if my choice doesn't win.
>   [ ] I definitively won't be using 1.4. if Wicket doesn't go for my
> preference.

Whatever the devs decide, I'm not going to stop using Wicket (or
refuse to upgrade forever more) just because they've not implemented
something exactly the way I personally prefer!  I have faith that,
with discussion, the "right" decision will be made for the framework
as a whole.  After all, if I weren't happy to go along with the
majority view, I'd have to write everything myself...

Charlie.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Stefan Jozsa-2]

Eelco Hillenius <eelco.hillenius@...> wrote:1) Generifying* Wicket
[X] They, the core developers, knows better then me
(everyday users doesn't have in-depth and extensive view on
generification pro and cons. As usual, to find a good compromise
may be _very_ tricky business).

2) How strongly do you feel about your choice above?
   [X] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.

Stefan Jozsa


       

[John Krasnay]

On Mon, Jun 02, 2008 at 11:59:09AM -0400, Hoover, William  wrote:
> I read it, but I think most people will be using models more frequently
> than 30% of the time. Personally, I use them 99% of the time.

Really? Haven't you heard of CompoundPropertyModel?

jk

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Bernard Niset-2]

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@...