generics in Wicket

[Eelco Hillenius]

Hi,

I think we went overboard applying generics in Wicket.

Things like:
TextField<Integer> integerTextField = new TextField<Integer>(this,
"integerProperty", Integer.class);

are just horrible imo. Sure, you can do:

Integer i = integerTextField.getModelObject();

instead of:

Integer i = (Integer)integerTextField.getModelObject();

but that's about the whole great benefit of generic components for the
price of about twice the verbosity.

Also, calling getModelObject is the kind of convenience method that
grew upon us but that I personally never liked. It saves an ugly model
check, fine, but in general I think users should try to directly work
with models and their underlying objects instead.

I can see the method come in handy in list views (on ListItem), though
then again, you know the model object would never be null there so
getModel().getObject() would work as well.

Anyway, what I'd like us to consider is to de-generify components and
only keep it for models. For certain components (like ListView) we/
users can decide to introduce it, but the general case would be to not
to.

Thoughts? Screams?

Eelco

[jcompagner-2]

no i am not pro for degenerifying it.
I like the getModelObject()

and that we have to do this:
 TextField<Integer> integerTextField = new
TextField<Integer>(this,"integerProperty", Integer.class);

is just suns fault of that stupid erasure :(

But i am curious about where people talk to
is it just the model or are people go through componet.getModelObject() ?

But then how would you generify only the models?

for example if we completely remove it from the components

then we have this?

TextField tf = new Textfield(new Model<String>("test"));

but how get we that model generified back in?

tf.getModel() should return Model<String> then because if we also loose that
then we can completely scrap it and i am really -1 about that.

johan



On 3/7/07, Eelco Hillenius <eelco.hillenius@...> wrote:

>
> Hi,
>
> I think we went overboard applying generics in Wicket.
>
> Things like:
> TextField<Integer> integerTextField = new TextField<Integer>(this,
> "integerProperty", Integer.class);
>
> are just horrible imo. Sure, you can do:
>
> Integer i = integerTextField.getModelObject();
>
> instead of:
>
> Integer i = (Integer)integerTextField.getModelObject();
>
> but that's about the whole great benefit of generic components for the
> price of about twice the verbosity.
>
> Also, calling getModelObject is the kind of convenience method that
> grew upon us but that I personally never liked. It saves an ugly model
> check, fine, but in general I think users should try to directly work
> with models and their underlying objects instead.
>
> I can see the method come in handy in list views (on ListItem), though
> then again, you know the model object would never be null there so
> getModel().getObject() would work as well.
>
> Anyway, what I'd like us to consider is to de-generify components and
> only keep it for models. For certain components (like ListView) we/
> users can decide to introduce it, but the general case would be to not
> to.
>
> Thoughts? Screams?
>
> Eelco
>

[Eelco Hillenius]

> no i am not pro for degenerifying it.
> I like the getModelObject()

What is so great about that method, and why don't you just directly
work with the objects the models work on? And why not
getModel().getObject?

> But i am curious about where people talk to
> is it just the model or are people go through componet.getModelObject() ?

I hope the first. getModelObject is a convenience method, and in some
case, like ListView's ListItem, it's the obvious thing to use.
However, think of all the textfields, dropdownlists and other form
components... no good using that method, imo. And what I never liked
about that method in the first place is that it pushes people in the
wrong direction. They should be thinking in models and the objects
they work on rather than 'values' of components. In the same fashion
I'm against setModelObject as well. If it were just up to me, I'd
remove it/ them (also because getModel().setObject can result in
something different then setModelObject).

> But then how would you generify only the models?
>
> for example if we completely remove it from the components
>
> then we have this?
>
> TextField tf = new Textfield(new Model<String>("test"));
>
> but how get we that model generified back in?
>
> tf.getModel() should return Model<String> then because if we also loose that
> then we can completely scrap it and i am really -1 about that.

Yeah, hmmm. I didn't actually think about that yet. Looking at it,
what I propose seems impossible? :(

Eelco

[jcompagner-2]

getModelObject has (in 1.3 not in 2.0) really a better function then
getModel().getObject(XXXX)
because getModelObject knows what to put in the XXXX
for example this is very different:

Form form = new Form("form", new CompoundModel(xxx));
Textfield tf = new Textfield("tf");
form.add(tf);

now if i want the tf model object i have to do: tf.getModel().getObject(tf)
and not null!
But if i want to get the model object of the Form i have to insert null and
NOT the form!
So in 1.3 the only reliable way to really get the right value out of a model
is to use getModelObject of component..

But if we backport the model changes then that is done inside the model and
that is much much cleaner (i am +1 for backporting that to 1.3)

johan


On 3/7/07, Eelco Hillenius <eelco.hillenius@...> wrote:

>
> > no i am not pro for degenerifying it.
> > I like the getModelObject()
>
> What is so great about that method, and why don't you just directly
> work with the objects the models work on? And why not
> getModel().getObject?
>
> > But i am curious about where people talk to
> > is it just the model or are people go through componet.getModelObject()
> ?
>
> I hope the first. getModelObject is a convenience method, and in some
> case, like ListView's ListItem, it's the obvious thing to use.
> However, think of all the textfields, dropdownlists and other form
> components... no good using that method, imo. And what I never liked
> about that method in the first place is that it pushes people in the
> wrong direction. They should be thinking in models and the objects
> they work on rather than 'values' of components. In the same fashion
> I'm against setModelObject as well. If it were just up to me, I'd
> remove it/ them (also because getModel().setObject can result in
> something different then setModelObject).
>
> > But then how would you generify only the models?
> >
> > for example if we completely remove it from the components
> >
> > then we have this?
> >
> > TextField tf = new Textfield(new Model<String>("test"));
> >
> > but how get we that model generified back in?
> >
> > tf.getModel() should return Model<String> then because if we also loose
> that
> > then we can completely scrap it and i am really -1 about that.
>
> Yeah, hmmm. I didn't actually think about that yet. Looking at it,
> what I propose seems impossible? :(
>
> Eelco
>

[Eelco Hillenius]

> But if we backport the model changes then that is done inside the model and
> that is much much cleaner (i am +1 for backporting that to 1.3)

+1 too. Especially considering the case you just described: ugly! :)

Eelco

[Martijn Dashorst]

What happened to the otherwise we break the API too much? I remember
putting up a vote for a model backport, but that time you did a -1 :-P

Martijn

On 3/7/07, Eelco Hillenius <eelco.hillenius@...> wrote:
> > But if we backport the model changes then that is done inside the model and
> > that is much much cleaner (i am +1 for backporting that to 1.3)
>
> +1 too. Especially considering the case you just described: ugly! :)
>
> Eelco
>


--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org

[igor.vaynberg]

you guys arent talking about putting it into 1.3 are you? can we please
finish with 1.3 already!

-igor


On 3/7/07, Martijn Dashorst <martijn.dashorst@...> wrote:

>
> What happened to the otherwise we break the API too much? I remember
> putting up a vote for a model backport, but that time you did a -1 :-P
>
> Martijn
>
> On 3/7/07, Eelco Hillenius <eelco.hillenius@...> wrote:
> > > But if we backport the model changes then that is done inside the
> model and
> > > that is much much cleaner (i am +1 for backporting that to 1.3)
> >
> > +1 too. Especially considering the case you just described: ugly! :)
> >
> > Eelco
> >
>
>
> --
> Learn Wicket at ApacheCon Europe: http://apachecon.com
> Join the wicket community at irc.freenode.net: ##wicket
> Wicket 1.2.5 will keep your server alive. Download Wicket now!
> http://wicketframework.org
>

[Stefan Lindner]

I am completely against degenerifying components. We have build a high abstraction framework with typed components that are reused in several other components and the generics help us to ensure to use the the use of the right component at the right place.
Besides some minor problems with suns generic implementation I think that generic are the most usefull thing for us in Java 5. Type checking at development time hels to speed up development a lot.
things like

     Integer i = (Integer)integerTextField.getModelObject();

always leads to problems at runtime whent the customer suddenly needs a Dobule field insteda of an Integer field.
And over and above this would be another API break.
 
Stefan Lindner

[Jonathan Locke]

don't worry.  i believe that reason will prevail.  i too am against a /complete/ degenerification, as are all the core developers.  we just want to lighten it up some without losing much.  in the case of typed textfields, there might be a workaround that doesn't force Component to be parameterized.  for example, maybe just TextField<T> is enough.  or maybe a typesafe accessor can provide what you want in an IntegerTextField subclass.  in any case, i think exactly how and where to degenerify things for whatever comes after 1.3 needs to be discussed at length and there should be plenty of time to talk reasonably.

can you provide more details of generics benefits you don't want to lose?

Stefan Lindner wrote:

I am completely against degenerifying components. We have build a high abstraction framework with typed components that are reused in several other components and the generics help us to ensure to use the the use of the right component at the right place.
Besides some minor problems with suns generic implementation I think that generic are the most usefull thing for us in Java 5. Type checking at development time hels to speed up development a lot.
things like

     Integer i = (Integer)integerTextField.getModelObject();

always leads to problems at runtime whent the customer suddenly needs a Dobule field insteda of an Integer field.
And over and above this would be another API break.
 
Stefan Lindner

[Stefan Lindner]

Maybe I am too accustomed to generics now but I can't imagine how a non-generic Component class definition with a generic Model parameter can look like.
Now Compinent is defined as
 
     class Component<T> ... {
          public Component(final MarkupContainer<?> parent, final String id, final IModel<T> model) {
          ...
          }
 
          public final T getModelObject() {
          ...
          }
 
How should a non generic class definition look like? And pepole that don't like or need generics can still use the raw types.
My preference for a strong gneric API comes from the experience I made when I moved from Wicket 1.2 to 2.0. The simple syntactic modifications for generic Components showed up several programming errors that we otherwise had to debug during runtime of the application. It also showed up some design problems of our applicatioin. So a strong generic API may took a little bit more time in developing an application but it saves much more time in debugging.
 
Stefan Lindner
 

[Eelco Hillenius]

It's good to see someone being happy with it and using it for
something real. I'm afraid my initial message was FUD anyway, as
looking into it a little bit closer, it doesn't seem like we have a
lot of choice. Seems to be either all or nothing. And as we can always
tell the compiler to ignore this stuff, I guess 'all' is the best
here.

Eelco

On 3/7/07, Stefan Lindner <lindner@...> wrote:

> Maybe I am too accustomed to generics now but I can't imagine how a non-generic Component class definition with a generic Model parameter can look like.
> Now Compinent is defined as
>
>      class Component<T> ... {
>           public Component(final MarkupContainer<?> parent, final String id, final IModel<T> model) {
>           ...
>           }
>
>           public final T getModelObject() {
>           ...
>           }
>
> How should a non generic class definition look like? And pepole that don't like or need generics can still use the raw types.
> My preference for a strong gneric API comes from the experience I made when I moved from Wicket 1.2 to 2.0. The simple syntactic modifications for generic Components showed up several programming errors that we otherwise had to debug during runtime of the application. It also showed up some design problems of our applicatioin. So a strong generic API may took a little bit more time in developing an application but it saves much more time in debugging.
>
> Stefan Lindner
>
>

[Eelco Hillenius]

> What happened to the otherwise we break the API too much? I remember
> putting up a vote for a model backport, but that time you did a -1 :-P

Yes. Back then I hoped we could make a first release by the end of
december as well. And as Johan ported converters as well yesterday,
this could go as well I thought.

Eelco

[Eelco Hillenius]

> you guys arent talking about putting it into 1.3 are you? can we please
> finish with 1.3 already!

We agreed that as long as 1.3 is in beta we could implement changes
that break the API. So we can make a release and still do that change.
Or do it in 1.4 if you like, but I don't want to even start on 1.4 if
we decide to keep 2.0 alive.

Eelco

[igor.vaynberg]

thats not the point! its not about api breaks. this is why 1.3 is taking
forever, you keep adding and adding and adding. finish 1.3, then add this
refactor to 1.4 lets release the damn thing already!

-igor


On 3/7/07, Eelco Hillenius <eelco.hillenius@...> wrote:

>
> > you guys arent talking about putting it into 1.3 are you? can we please
> > finish with 1.3 already!
>
> We agreed that as long as 1.3 is in beta we could implement changes
> that break the API. So we can make a release and still do that change.
> Or do it in 1.4 if you like, but I don't want to even start on 1.4 if
> we decide to keep 2.0 alive.
>
> Eelco
>

[Jonathan Locke]

the imodel wouldn't be generic in component.  only in subclasses.  i actually mildly prefer total generification too, but a lot of people have expressed annoyance at generic code bulk so i've been listening to that.  basically, getModelObject would return Object below, but ListView<T> would return T.  or that was the idea... i'm not sure if it's good.  i just wanted us to discuss it to see what's there.

Stefan Lindner wrote:

Maybe I am too accustomed to generics now but I can't imagine how a non-generic Component class definition with a generic Model parameter can look like.
Now Compinent is defined as
 
     class Component<T> ... {
          public Component(final MarkupContainer<?> parent, final String id, final IModel<T> model) {
          ...
          }
 
          public final T getModelObject() {
          ...
          }
 
How should a non generic class definition look like? And pepole that don't like or need generics can still use the raw types.
My preference for a strong gneric API comes from the experience I made when I moved from Wicket 1.2 to 2.0. The simple syntactic modifications for generic Components showed up several programming errors that we otherwise had to debug during runtime of the application. It also showed up some design problems of our applicatioin. So a strong generic API may took a little bit more time in developing an application but it saves much more time in debugging.
 
Stefan Lindner
 

[jcompagner-2]

i have the same feeling, and i also don't think we can drop one and still
have the other like we want.
So i guess we are stuck with what we have because i don't want completely
gone.

johan



On 3/7/07, Stefan Lindner <lindner@...> wrote:

>
> Maybe I am too accustomed to generics now but I can't imagine how a
> non-generic Component class definition with a generic Model parameter can
> look like.
> Now Compinent is defined as
>
>      class Component<T> ... {
>           public Component(final MarkupContainer<?> parent, final String
> id, final IModel<T> model) {
>           ...
>           }
>
>           public final T getModelObject() {
>           ...
>           }
>
> How should a non generic class definition look like? And pepole that don't
> like or need generics can still use the raw types.
> My preference for a strong gneric API comes from the experience I made
> when I moved from Wicket 1.2 to 2.0. The simple syntactic modifications
> for generic Components showed up several programming errors that we
> otherwise had to debug during runtime of the application. It also showed up
> some design problems of our applicatioin. So a strong generic API may took a
> little bit more time in developing an application but it saves much more
> time in debugging.
>
> Stefan Lindner
>
>

[jcompagner-2]

no that is not the case
We don't wait for features or wait because we add stuff!
We wait for the apache things that we have to do.

So dropping in new features until that is resolved is not really a problem
and those features are already tested by everybody that uses 2.0
So also backporting those is not a problem for me. I can patch it the coming
days.
if ofcourse others also want it.

johan




On 3/7/07, Igor Vaynberg <igor.vaynberg@...> wrote:

>
> thats not the point! its not about api breaks. this is why 1.3 is taking
> forever, you keep adding and adding and adding. finish 1.3, then add this
> refactor to 1.4 lets release the damn thing already!
>
> -igor
>
>
> On 3/7/07, Eelco Hillenius <eelco.hillenius@...> wrote:
> >
> > > you guys arent talking about putting it into 1.3 are you? can we
> please
> > > finish with 1.3 already!
> >
> > We agreed that as long as 1.3 is in beta we could implement changes
> > that break the API. So we can make a release and still do that change.
> > Or do it in 1.4 if you like, but I don't want to even start on 1.4 if
> > we decide to keep 2.0 alive.
> >
> > Eelco
> >
>

[jcompagner-2]

But what is the problem then?
You do want the textfield?
But the component isn't really in your way and does give you
getModelObject()
i don't see the point of deleting it from Component but keeping it for
pretty much everything else

johan


On 3/7/07, Jonathan Locke <jonathan.locke@...> wrote:

>
>
>
> the imodel wouldn't be generic in component.  only in subclasses.  i
> actually mildly prefer total generification too, but a lot of people have
> expressed annoyance at generic code bulk so i've been listening to that.
> basically, getModelObject would return Object below, but ListView<T> would
> return T.  or that was the idea... i'm not sure if it's good.  i just
> wanted
> us to discuss it to see what's there.
>
>
> Stefan Lindner wrote:
> >
> > Maybe I am too accustomed to generics now but I can't imagine how a
> > non-generic Component class definition with a generic Model parameter
> can
> > look like.
> > Now Compinent is defined as
> >
> >      class Component<T> ... {
> >           public Component(final MarkupContainer<?> parent, final String
> > id, final IModel<T> model) {
> >           ...
> >           }
> >
> >           public final T getModelObject() {
> >           ...
> >           }
> >
> > How should a non generic class definition look like? And pepole that
> don't
> > like or need generics can still use the raw types.
> > My preference for a strong gneric API comes from the experience I made
> > when I moved from Wicket 1.2 to 2.0. The simple syntactic modifications
> > for generic Components showed up several programming errors that we
> > otherwise had to debug during runtime of the application. It also showed
> > up some design problems of our applicatioin. So a strong generic API may
> > took a little bit more time in developing an application but it saves
> much
> > more time in debugging.
> >
> > Stefan Lindner
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/generics-in-Wicket-tf3360271.html#a9356570
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>

[Eelco Hillenius]

> thats not the point! its not about api breaks. this is why 1.3 is taking
> forever, you keep adding and adding and adding.

What are you talking about? 1.3's release wasn't/ isn't postponed a
single day because of us adding new features. The opposite is true:
new features (like the converter change) are added because the release
isn't out yet and it's still ok to add (or backport) features.

No, there is no 1.3 release yet for two (and only two) reasons:
1) legal issues due to incubating
2) setting up the new release process and being short in time for some
members who are working on that

Eelco

[Eelco Hillenius]

> no that is not the case
> We don't wait for features or wait because we add stuff!
> We wait for the apache things that we have to do.
>
> So dropping in new features until that is resolved is not really a problem
> and those features are already tested by everybody that uses 2.0
> So also backporting those is not a problem for me. I can patch it the coming
> days.
> if ofcourse others also want it.

Johan++ :)

Eelco