|
Re: generics in Wicket
oh please. the more stuff you add the more we have to test, the longer it
takes. johan is talking about backporting the models and thats great, but he
still hasnt fixed the serialization issues in the pagestore. we needed a
feature freeze a long time ago, so that we _would_ concentrate on getting
the legal issues resolved, but instead weve been happily hacking away. we
should at least try to work on some bugs before adding new stuff in.
-igor
On 3/7/07, Eelco Hillenius < eelco.hillenius@...> 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.
>
> 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
>
|
|
Re: generics in Wicket
We have a team of over ten people, so I don't see why backporting
features can't be done, especially as some are without a doubt worth
it. Take the converter backport. We made at least two users happy
already! And it makes no difference AT ALL to the speed at which the
release comes. The release isn't bound to testing anyway, as the first
goal of the upcoming release is to have a dry run for an Apache ok-ed
release.
Eelco
On 3/7/07, Igor Vaynberg < igor.vaynberg@...> wrote:
> oh please. the more stuff you add the more we have to test, the longer it
> takes. johan is talking about backporting the models and thats great, but he
> still hasnt fixed the serialization issues in the pagestore. we needed a
> feature freeze a long time ago, so that we _would_ concentrate on getting
> the legal issues resolved, but instead weve been happily hacking away. we
> should at least try to work on some bugs before adding new stuff in.
>
> -igor
>
>
> On 3/7/07, Eelco Hillenius < eelco.hillenius@...> 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.
> >
> > 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
> >
>
|
|
Re: generics in Wicket
and how many users did you make unhappy with the half working pagestore?
maybe that shouldve been fixed before more energy was spent on backporting
the converters.
-igor
On 3/7/07, Eelco Hillenius < eelco.hillenius@...> wrote:
>
> We have a team of over ten people, so I don't see why backporting
> features can't be done, especially as some are without a doubt worth
> it. Take the converter backport. We made at least two users happy
> already! And it makes no difference AT ALL to the speed at which the
> release comes. The release isn't bound to testing anyway, as the first
> goal of the upcoming release is to have a dry run for an Apache ok-ed
> release.
>
> Eelco
>
>
> On 3/7/07, Igor Vaynberg < igor.vaynberg@...> wrote:
> > oh please. the more stuff you add the more we have to test, the longer
> it
> > takes. johan is talking about backporting the models and thats great,
> but he
> > still hasnt fixed the serialization issues in the pagestore. we needed a
> > feature freeze a long time ago, so that we _would_ concentrate on
> getting
> > the legal issues resolved, but instead weve been happily hacking away.
> we
> > should at least try to work on some bugs before adding new stuff in.
> >
> > -igor
> >
> >
> > On 3/7/07, Eelco Hillenius < eelco.hillenius@...> 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.
> > >
> > > 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
> > >
> >
>
|
|
Re: generics in Wicket
On 3/7/07, Igor Vaynberg < igor.vaynberg@...> wrote:
> and how many users did you make unhappy with the half working pagestore?
> maybe that shouldve been fixed before more energy was spent on backporting
> the converters.
Didn't you +1 on setting that as the default, something I proposed /not/ doing?
Eelco
|
|
Re: generics in Wicket
yes, but i figured johan was going to keep working on it instead of
backporting new features :)
-igor
On 3/7/07, Eelco Hillenius < eelco.hillenius@...> wrote:
>
> On 3/7/07, Igor Vaynberg < igor.vaynberg@...> wrote:
> > and how many users did you make unhappy with the half working pagestore?
> > maybe that shouldve been fixed before more energy was spent on
> backporting
> > the converters.
>
> Didn't you +1 on setting that as the default, something I proposed /not/
> doing?
>
> Eelco
>
|
|
Re: generics in Wicket
ah. good point. so we should remove generics from subclasses that don't benefit. how's that sound?
Johan Compagner wrote:
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@gmail.com> 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.
>
>
|
|
Re: generics in Wicket
It was my rather limited energy that did the converter backport.
Thus Johan can't use this effort as an excuse, that the pagestore isn't
working already ;).
Sven
Igor Vaynberg wrote:
> and how many users did you make unhappy with the half working pagestore?
> maybe that shouldve been fixed before more energy was spent on
> backporting
> the converters.
>
> -igor
>
>
> On 3/7/07, Eelco Hillenius < eelco.hillenius@...> wrote:
>>
>> We have a team of over ten people, so I don't see why backporting
>> features can't be done, especially as some are without a doubt worth
>> it. Take the converter backport. We made at least two users happy
>> already! And it makes no difference AT ALL to the speed at which the
>> release comes. The release isn't bound to testing anyway, as the first
>> goal of the upcoming release is to have a dry run for an Apache ok-ed
>> release.
>>
>> Eelco
>>
>>
>> On 3/7/07, Igor Vaynberg < igor.vaynberg@...> wrote:
>> > oh please. the more stuff you add the more we have to test, the longer
>> it
>> > takes. johan is talking about backporting the models and thats great,
>> but he
>> > still hasnt fixed the serialization issues in the pagestore. we
>> needed a
>> > feature freeze a long time ago, so that we _would_ concentrate on
>> getting
>> > the legal issues resolved, but instead weve been happily hacking away.
>> we
>> > should at least try to work on some bugs before adding new stuff in.
>> >
>> > -igor
>> >
>> >
>> > On 3/7/07, Eelco Hillenius < eelco.hillenius@...> 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.
>> > >
>> > > 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
>> > >
>> >
>>
>
|
|
Re: generics in Wicket
On 3/7/07, Sven Meier < sven@...> wrote:
> It was my rather limited energy that did the converter backport.
Ah. Thanks though!
> Thus Johan can't use this effort as an excuse, that the pagestore isn't
> working already ;).
Nope he can't. Get on it Johan! :)
Eelco
|
|
RE: generics in Wicket
Stefan Lindner wrote:
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.
I agree with this. We had the same experience, moving from 1.x to 2.0. Applying generics to complex component/model interactions can be hard (f.i. models working with collections, wrapmodels that define a different object than the nested model,...), but it clearly identifies where the design is not correct.
We are in favor of maintaining generics.
Jan.
|
|
Re: generics in Wicket
why?
that one can be simple disabled. PageStore works perfectly without it.
I think our in/output will always jump into cases that are not completely
supported
If that is the case. Then use the default one.
Converters didn't cost me time (it was a patch)
johan
On 3/7/07, Igor Vaynberg < igor.vaynberg@...> wrote:
>
> and how many users did you make unhappy with the half working pagestore?
> maybe that shouldve been fixed before more energy was spent on backporting
> the converters.
>
> -igor
>
>
> On 3/7/07, Eelco Hillenius < eelco.hillenius@...> wrote:
> >
> > We have a team of over ten people, so I don't see why backporting
> > features can't be done, especially as some are without a doubt worth
> > it. Take the converter backport. We made at least two users happy
> > already! And it makes no difference AT ALL to the speed at which the
> > release comes. The release isn't bound to testing anyway, as the first
> > goal of the upcoming release is to have a dry run for an Apache ok-ed
> > release.
> >
> > Eelco
> >
> >
> > On 3/7/07, Igor Vaynberg < igor.vaynberg@...> wrote:
> > > oh please. the more stuff you add the more we have to test, the longer
> > it
> > > takes. johan is talking about backporting the models and thats great,
> > but he
> > > still hasnt fixed the serialization issues in the pagestore. we needed
> a
> > > feature freeze a long time ago, so that we _would_ concentrate on
> > getting
> > > the legal issues resolved, but instead weve been happily hacking away.
> > we
> > > should at least try to work on some bugs before adding new stuff in.
> > >
> > > -igor
> > >
> > >
> > > On 3/7/07, Eelco Hillenius < eelco.hillenius@...> 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.
> > > >
> > > > 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
> > > >
> > >
> >
>
|
|
Re: generics in Wicket
i always did say +1 (but i also said that i would do it when i fixed it)
But again. This is purely for testing and pagestore is not halfbaked. That
one is currently
pretty perfect and heavily tested (thx matej!). The wicket serialization is
just an extra
that will be on going work.
johan
On 3/7/07, Eelco Hillenius < eelco.hillenius@...> wrote:
>
> On 3/7/07, Igor Vaynberg < igor.vaynberg@...> wrote:
> > and how many users did you make unhappy with the half working pagestore?
> > maybe that shouldve been fixed before more energy was spent on
> backporting
> > the converters.
>
> Didn't you +1 on setting that as the default, something I proposed /not/
> doing?
>
> Eelco
>
|
|
Re: generics in Wicket
Sven+++!
and no i will not use it as an excuse!
On 3/7/07, Sven Meier < sven@...> wrote:
>
> It was my rather limited energy that did the converter backport.
>
> Thus Johan can't use this effort as an excuse, that the pagestore isn't
> working already ;).
>
> Sven
>
> Igor Vaynberg wrote:
> > and how many users did you make unhappy with the half working pagestore?
> > maybe that shouldve been fixed before more energy was spent on
> > backporting
> > the converters.
> >
> > -igor
> >
> >
> > On 3/7/07, Eelco Hillenius < eelco.hillenius@...> wrote:
> >>
> >> We have a team of over ten people, so I don't see why backporting
> >> features can't be done, especially as some are without a doubt worth
> >> it. Take the converter backport. We made at least two users happy
> >> already! And it makes no difference AT ALL to the speed at which the
> >> release comes. The release isn't bound to testing anyway, as the first
> >> goal of the upcoming release is to have a dry run for an Apache ok-ed
> >> release.
> >>
> >> Eelco
> >>
> >>
> >> On 3/7/07, Igor Vaynberg < igor.vaynberg@...> wrote:
> >> > oh please. the more stuff you add the more we have to test, the
> longer
> >> it
> >> > takes. johan is talking about backporting the models and thats great,
> >> but he
> >> > still hasnt fixed the serialization issues in the pagestore. we
> >> needed a
> >> > feature freeze a long time ago, so that we _would_ concentrate on
> >> getting
> >> > the legal issues resolved, but instead weve been happily hacking
> away.
> >> we
> >> > should at least try to work on some bugs before adding new stuff in.
> >> >
> >> > -igor
> >> >
> >> >
> >> > On 3/7/07, Eelco Hillenius < eelco.hillenius@...> 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.
> >> > >
> >> > > 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
> >> > >
> >> >
> >>
> >
>
>
|
|
Re: generics in Wicket
I think generic components are a mistake for several reasons. Not
only is the snippet below ugly and redundant, it doesn't even save a
cast if you're using a CompoundPropertyModel (which is the most
common case in my app). Well, I guess you save one cast, but that's
for the parent component's model, not for the form components
themselves.
At least for FormComponents, it's relatively obvious that a
component's type == its model type. But what does it mean to specify
the type for a Panel, Link, WebMarkupContainer, etc. when you're not
even going to assign a model to the component (again, a fairly common
case)? I think classes that make sense as generics don't have this
problem -- they always hold, accept or return objects of their
specified type.
A lot of this boils down to the fact that a component's type
parameter really has little to do with the component itself. It's for
the underlying model (including validation/conversion to the model's
object). Specifying the model's type in the component tightly couples
the two together, which clashes with Wicket's concept of models as
independent and dynamically resolvable objects (not to mention
clashing with MVC in general).
So, I completely agree with everything you said below and just wanted
to throw out a "-1" for generic components hopefully before a final
decision is made.
-Ryan
On Mar 6, 2007, at 9:57 PM, 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
|
|
Re: generics in Wicket
Hi Ryan,
The problem is - I found out later - that we can't really generify
models in a meaningful way without generifying components as well. At
least, I haven't found a good way.
Do you have concrete suggestions or a proposal of how we could
implement generics in a meaningful but non-obstrusive way?
Eelco
On 3/18/07, Ryan Holmes < ryan@...> wrote:
> I think generic components are a mistake for several reasons. Not
> only is the snippet below ugly and redundant, it doesn't even save a
> cast if you're using a CompoundPropertyModel (which is the most
> common case in my app). Well, I guess you save one cast, but that's
> for the parent component's model, not for the form components
> themselves.
>
> At least for FormComponents, it's relatively obvious that a
> component's type == its model type. But what does it mean to specify
> the type for a Panel, Link, WebMarkupContainer, etc. when you're not
> even going to assign a model to the component (again, a fairly common
> case)? I think classes that make sense as generics don't have this
> problem -- they always hold, accept or return objects of their
> specified type.
>
> A lot of this boils down to the fact that a component's type
> parameter really has little to do with the component itself. It's for
> the underlying model (including validation/conversion to the model's
> object). Specifying the model's type in the component tightly couples
> the two together, which clashes with Wicket's concept of models as
> independent and dynamically resolvable objects (not to mention
> clashing with MVC in general).
>
> So, I completely agree with everything you said below and just wanted
> to throw out a "-1" for generic components hopefully before a final
> decision is made.
>
> -Ryan
>
>
> On Mar 6, 2007, at 9:57 PM, 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
>
>
|
|
Re: generics in Wicket
the thing is the model ties into a few places in the component
for example IConverter Component.getConverter(). it would be nice to say new
WebMarkupContainer<Person> { IConverter<Person> getConverter() {...}}
things like that
-igor
On 3/18/07, Eelco Hillenius < eelco.hillenius@...> wrote:
>
> Hi Ryan,
>
> The problem is - I found out later - that we can't really generify
> models in a meaningful way without generifying components as well. At
> least, I haven't found a good way.
>
> Do you have concrete suggestions or a proposal of how we could
> implement generics in a meaningful but non-obstrusive way?
>
> Eelco
>
>
> On 3/18/07, Ryan Holmes < ryan@...> wrote:
> > I think generic components are a mistake for several reasons. Not
> > only is the snippet below ugly and redundant, it doesn't even save a
> > cast if you're using a CompoundPropertyModel (which is the most
> > common case in my app). Well, I guess you save one cast, but that's
> > for the parent component's model, not for the form components
> > themselves.
> >
> > At least for FormComponents, it's relatively obvious that a
> > component's type == its model type. But what does it mean to specify
> > the type for a Panel, Link, WebMarkupContainer, etc. when you're not
> > even going to assign a model to the component (again, a fairly common
> > case)? I think classes that make sense as generics don't have this
> > problem -- they always hold, accept or return objects of their
> > specified type.
> >
> > A lot of this boils down to the fact that a component's type
> > parameter really has little to do with the component itself. It's for
> > the underlying model (including validation/conversion to the model's
> > object). Specifying the model's type in the component tightly couples
> > the two together, which clashes with Wicket's concept of models as
> > independent and dynamically resolvable objects (not to mention
> > clashing with MVC in general).
> >
> > So, I completely agree with everything you said below and just wanted
> > to throw out a "-1" for generic components hopefully before a final
> > decision is made.
> >
> > -Ryan
> >
> >
> > On Mar 6, 2007, at 9:57 PM, 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
> >
> >
>
|
|
Re: generics in Wicket
Well, you could make getModel() and setModel() generic methods rather
than specifying the model's type on the component. That would allow
for generic models without generifying the entire framework to get them.
I checked out 2.0 to see how generics work inside the framework. I
have to say it looks like some horrible angle-bracket disease has
infected the code base ;). The heavy use of <?> and raw type
references to component classes reinforces my opinion that components
simply don't lend themselves to generification.
-Ryan
On Mar 18, 2007, at 5:43 PM, Eelco Hillenius wrote:
> Hi Ryan,
>
> The problem is - I found out later - that we can't really generify
> models in a meaningful way without generifying components as well. At
> least, I haven't found a good way.
>
> Do you have concrete suggestions or a proposal of how we could
> implement generics in a meaningful but non-obstrusive way?
>
> Eelco
>
>
> On 3/18/07, Ryan Holmes < ryan@...> wrote:
>> I think generic components are a mistake for several reasons. Not
>> only is the snippet below ugly and redundant, it doesn't even save a
>> cast if you're using a CompoundPropertyModel (which is the most
>> common case in my app). Well, I guess you save one cast, but that's
>> for the parent component's model, not for the form components
>> themselves.
>>
>> At least for FormComponents, it's relatively obvious that a
>> component's type == its model type. But what does it mean to specify
>> the type for a Panel, Link, WebMarkupContainer, etc. when you're not
>> even going to assign a model to the component (again, a fairly common
>> case)? I think classes that make sense as generics don't have this
>> problem -- they always hold, accept or return objects of their
>> specified type.
>>
>> A lot of this boils down to the fact that a component's type
>> parameter really has little to do with the component itself. It's for
>> the underlying model (including validation/conversion to the model's
>> object). Specifying the model's type in the component tightly couples
>> the two together, which clashes with Wicket's concept of models as
>> independent and dynamically resolvable objects (not to mention
>> clashing with MVC in general).
>>
>> So, I completely agree with everything you said below and just wanted
>> to throw out a "-1" for generic components hopefully before a final
>> decision is made.
>>
>> -Ryan
>>
>>
>> On Mar 6, 2007, at 9:57 PM, 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
>>
>>
|
|
Re: generics in Wicket
Sure, but converters shouldn't necessarily be more tightly coupled to
models either. Converters might use more fine grained types than a
model, for instance (although I do see your point -- if objects are
naturally tightly coupled there's no reason to pretend they're not).
I guess I'm looking at this from a fundamentally different point of
view: I've been getting by just fine with Wicket 1.2 (better than
fine -- I freakin' love it) and haven't once been bothered by the
lack of generics. I end up with maybe one or two casts in a page
which just isn't a big deal. At the same time, generic components
seem to add little and cost a lot in terms of productivity,
readability and upgrade effort.
So I totally agree that some things are nicer with generics. But that
doesn't mean that generic components are the right design. I mean,
are there demonstrable advantages to generic components that make
Wicket a better framework and/or improve the API from a user's point
of view? Or are generic components strictly a side-effect of generic
models?
-Ryan
On Mar 18, 2007, at 6:35 PM, Igor Vaynberg wrote:
> the thing is the model ties into a few places in the component
>
> for example IConverter Component.getConverter(). it would be nice
> to say new
> WebMarkupContainer<Person> { IConverter<Person> getConverter() {...}}
>
> things like that
>
> -igor
>
>
> On 3/18/07, Eelco Hillenius < eelco.hillenius@...> wrote:
>>
>> Hi Ryan,
>>
>> The problem is - I found out later - that we can't really generify
>> models in a meaningful way without generifying components as well. At
>> least, I haven't found a good way.
>>
>> Do you have concrete suggestions or a proposal of how we could
>> implement generics in a meaningful but non-obstrusive way?
>>
>> Eelco
>>
>>
>> On 3/18/07, Ryan Holmes < ryan@...> wrote:
>> > I think generic components are a mistake for several reasons. Not
>> > only is the snippet below ugly and redundant, it doesn't even
>> save a
>> > cast if you're using a CompoundPropertyModel (which is the most
>> > common case in my app). Well, I guess you save one cast, but that's
>> > for the parent component's model, not for the form components
>> > themselves.
>> >
>> > At least for FormComponents, it's relatively obvious that a
>> > component's type == its model type. But what does it mean to
>> specify
>> > the type for a Panel, Link, WebMarkupContainer, etc. when you're
>> not
>> > even going to assign a model to the component (again, a fairly
>> common
>> > case)? I think classes that make sense as generics don't have this
>> > problem -- they always hold, accept or return objects of their
>> > specified type.
>> >
>> > A lot of this boils down to the fact that a component's type
>> > parameter really has little to do with the component itself.
>> It's for
>> > the underlying model (including validation/conversion to the
>> model's
>> > object). Specifying the model's type in the component tightly
>> couples
>> > the two together, which clashes with Wicket's concept of models as
>> > independent and dynamically resolvable objects (not to mention
>> > clashing with MVC in general).
>> >
>> > So, I completely agree with everything you said below and just
>> wanted
>> > to throw out a "-1" for generic components hopefully before a final
>> > decision is made.
>> >
>> > -Ryan
>> >
>> >
>> > On Mar 6, 2007, at 9:57 PM, 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
>> >
>> >
>>
|
|
Re: generics in Wicket
> Or are generic components strictly a side-effect of generic
> models?
The latter imho. I've played around with it a bit, and I couldn't
really find a way to have generified models in a meaningful way
without having to generify components as well.
The main potential advantage that I see in applying generics in Wicket
would be the ability to force specific types of models for certain
components. But now take the case where you say we'll keep it minimal
and just use generic methods:
public <T> Component(final String id, final IModel<T> model)
would work, and you could define a component like:
public UserDetailsComponent(final String id, final IModel<User> object)
However, this won't help a lot as getModel would only return the raw
type, and we can't override setModel with IModel<String> either.
get/setModelObject won't work either (though as I've stated before, I
could live without those methods in the first place).
Do you have an idea that works without having to generify Component?
Eelco
|
|
Re: generics in Wicket
Compound models are working fine with generics (in 2.0)
Link can also have a model object (that you use when you click on the link)
But the problem is that warnings should be easier to disable for certain
situations..
Like the markupcontainter when you don't use the model at all..
for example this could give me an warning:
Link link = new Link("test", new Model("string"));
but this shouldn't:
Link link = new Link("test");
because i don't use a model.. Ofcourse in the second way it should be
possible (if using compound)
but not really needed. (no warning)
johan
On 3/19/07, Ryan Holmes < ryan@...> wrote:
>
> I think generic components are a mistake for several reasons. Not
> only is the snippet below ugly and redundant, it doesn't even save a
> cast if you're using a CompoundPropertyModel (which is the most
> common case in my app). Well, I guess you save one cast, but that's
> for the parent component's model, not for the form components
> themselves.
>
> At least for FormComponents, it's relatively obvious that a
> component's type == its model type. But what does it mean to specify
> the type for a Panel, Link, WebMarkupContainer, etc. when you're not
> even going to assign a model to the component (again, a fairly common
> case)? I think classes that make sense as generics don't have this
> problem -- they always hold, accept or return objects of their
> specified type.
>
> A lot of this boils down to the fact that a component's type
> parameter really has little to do with the component itself. It's for
> the underlying model (including validation/conversion to the model's
> object). Specifying the model's type in the component tightly couples
> the two together, which clashes with Wicket's concept of models as
> independent and dynamically resolvable objects (not to mention
> clashing with MVC in general).
>
> So, I completely agree with everything you said below and just wanted
> to throw out a "-1" for generic components hopefully before a final
> decision is made.
>
> -Ryan
>
>
> On Mar 6, 2007, at 9:57 PM, 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
>
>
|
|
Re: generics in Wicket
Guys,
I've used generics with 2.0 at length, and absolutely love them. I am a huge fan of catching a problem early with compile-time errors rather than finding out later that I'm returning the wrong type from a model or that my Formatter is expecting a different type. Yes, for a while the angle brackets are ugly and annoying. Heck the first time I saw C style language, I thought that all the braces where ugly as sin. When I first began using annotations, I found it hard to read. Now? I've used all these things and have learned how to read them without having to stare at them a long time. Now I can move on to using them to make my code better.
You do not *have* to use generics even with a generified framework. You will have to do a lot of casting and get a lot of compiler warnings, but it is not required. Nothing keeps you from defining a variable as a ListChoice rather than ListChoice<MyUserBean>. I, on the other hand use ListChoice<MyUserBean> extensively. To take that away would require that I touch a lot of code. For you, it requires that you ignore compiler warnings.
All in all, I don't care much about the constructor change, but I consider generics to be a must-have.
Anyway, that's my 2 cents. Your mileage may vary, of course.
On Sun, 2007-03-18 at 22:22 -0700, Ryan Holmes wrote:
Sure, but converters shouldn't necessarily be more tightly coupled to
models either. Converters might use more fine grained types than a
model, for instance (although I do see your point -- if objects are
naturally tightly coupled there's no reason to pretend they're not).
I guess I'm looking at this from a fundamentally different point of
view: I've been getting by just fine with Wicket 1.2 (better than
fine -- I freakin' love it) and haven't once been bothered by the
lack of generics. I end up with maybe one or two casts in a page
which just isn't a big deal. At the same time, generic components
seem to add little and cost a lot in terms of productivity,
readability and upgrade effort.
So I totally agree that some things are nicer with generics. But that
doesn't mean that generic components are the right design. I mean,
are there demonstrable advantages to generic components that make
Wicket a better framework and/or improve the API from a user's point
of view? Or are generic components strictly a side-effect of generic
models?
-Ryan
On Mar 18, 2007, at 6:35 PM, Igor Vaynberg wrote:
> the thing is the model ties into a few places in the component
>
> for example IConverter Component.getConverter(). it would be nice
> to say new
> WebMarkupContainer<Person> { IConverter<Person> getConverter() {...}}
>
> things like that
>
> -igor
>
>
> On 3/18/07, Eelco Hillenius <eelco.hillenius@...> wrote:
>>
>> Hi Ryan,
>>
>> The problem is - I found out later - that we can't really generify
>> models in a meaningful way without generifying components as well. At
>> least, I haven't found a good way.
>>
>> Do you have concrete suggestions or a proposal of how we could
>> implement generics in a meaningful but non-obstrusive way?
>>
>> Eelco
>>
>>
>> On 3/18/07, Ryan Holmes <ryan@...> wrote:
>> > I think generic components are a mistake for several reasons. Not
>> > only is the snippet below ugly and redundant, it doesn't even
>> save a
>> > cast if you're using a CompoundPropertyModel (which is the most
>> > common case in my app). Well, I guess you save one cast, but that's
>> > for the parent component's model, not for the form components
>> > themselves.
>> >
>> > At least for FormComponents, it's relatively obvious that a
>> > component's type == its model type. But what does it mean to
>> specify
>> > the type for a Panel, Link, WebMarkupContainer, etc. when you're
>> not
>> > even going to assign a model to the component (again, a fairly
>> common
>> > case)? I think classes that make sense as generics don't have this
>> > problem -- they always hold, accept or return objects of their
>> > specified type.
>> >
>> > A lot of this boils down to the fact that a component's type
>> > parameter really has little to do with the component itself.
>> It's for
>> > the underlying model (including validation/conversion to the
>> model's
>> > object). Specifying the model's type in the component tightly
>> couples
>> > the two together, which clashes with Wicket's concept of models as
>> > independent and dynamically resolvable objects (not to mention
>> > clashing with MVC in general).
>> >
>> > So, I completely agree with everything you said below and just
>> wanted
>> > to throw out a "-1" for generic components hopefully before a final
>> > decision is made.
>> >
>> > -Ryan
>> >
>> >
>> > On Mar 6, 2007, at 9:57 PM, 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
>> >
>> >
>>
--
Philip A. Chapman
Desktop and Web Application Development:
Java, .NET, PostgreSQL, MySQL, MSSQL
Linux, Windows 2000, Windows XP
|
|
signature.asc (196 bytes) 