You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Eelco Hillenius <ee...@gmail.com> on 2007/03/07 06:57:11 UTC
generics in Wicket
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
Posted by Ryan Holmes <ry...@hyperstep.com>.
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 <ry...@hyperstep.com> 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
Posted by Ryan Holmes <ry...@hyperstep.com>.
Thanks for the feedback Philip.
I use property models, especially CompoundPropertyModel, extensively
and wouldn't consider using a framework that didn't have good support
for property binding. It saves a huge amount of development time.
The reason I don't think it's sufficient to say "use
@SuppressWarnings" is because 1) a well-designed framework shouldn't
require you to suppress compiler warnings in the first place (at
least not very often) and 2) unless I'm going to apply that
annotation on an almost line-by-line basis, it can hide warnings that
I want to see.
We've been using generics at my work for quite a while now, written a
lot of generic classes, etc. and only have a handful of
@SuppressWarnings("unchecked") annotations. If you look at how/where
generics have been applied in the JDK, they tend to be on classes
that do little more than hold and operate on objects of their
declared type or are otherwise naturally strongly associated with
that type. Therefore, there's rarely a need to use the raw versions
of those classes.
Component, on the other hand, mostly consists of methods that do not
use the declared type and I think typical usage (which probably
involves a lot of property models and markup containers) leads to a
majority of Component instances deriving no benefit from specifying a
model type.
I don't think your tool analogy holds up here, because generics don't
add any new functionality. There's nothing you can do with generics
that you can't do without them.
Unfortunately, I think like/dislike of generics in Wicket is largely
a matter of style. It's tough to come up with quantitative points for
or against.
-Ryan
On Mar 20, 2007, at 3:37 AM, Philip A. Chapman wrote:
> Ryan,
>
> I do not use property models much, so that's part of the difference
> between our points of view (our coding styles). However, I do have
> at least one page that uses one. In that case, I forgo generics.
> I define raw types and set @SuppressWarnings("unchecked") on the
> methods that access them:
>
> JTextField tf = new JTextField(this, "stringProperty");
>
> I would like to make the point that when I do use PropertyModels, I
> usually throw away my component anyway (I don't usually assign it
> to a variable) because I only really care about the Model and the
> data in it anyway. The above code snippet was just an example.
>
> The @SuppressWarnings annotation tells the compiler to shut up and
> not bother me about it 'cause I know what I'm doing. The case that
> I alluded to and Ivan asked about specifically is "What about those
> components where generics really does matter?" Two components that
> he suggested really need generics are DropDownChoice and ListView.
> There are others, but this raises a point. I think that the
> problem that the wicket devs ran into early on is that either all
> components are generified or none (because of the models).
>
> I think that my statement before is still a valid and is
> strengthened above. If generic components are not appropriate for
> the code that you are writing, don't use them. It's OK. It's
> better for you to have a torx screwdriver in our common toolbox
> that you seldom use than to throw it out and I have non, but need
> it daily.
>
> Thanks,
>
> On Mon, 2007-03-19 at 22:03 -0700, Ryan Holmes wrote:
>> It's not that I don't like generics -- I just don't think
>> Component makes sense as a generic class because it seems like the
>> majority of use cases don't call for specifying a model type. Let
>> me ask you, do you specify the type for form components even when
>> you're using a CompoundPropertyModel (i.e. when you're never going
>> to call getModel() or getModelObject() directly on those
>> components)? And what about MarkupContainers and other components
>> that you usually don't assign a model to? -Ryan On Mar 19, 2007,
>> at 11:25 AM, Philip A. Chapman wrote: > 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 >>
>> <ee...@gmail.com> 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 <ry...@hyperstep.com>
>> 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
> -- Philip A. Chapman Desktop and Web Application Development:
> Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP
Re: generics in Wicket
Posted by "Philip A. Chapman" <pc...@pcsw.us>.
On Tue, 2007-03-20 at 05:37 -0500, Philip A. Chapman wrote:
>
> JTextField tf = new JTextField(this, "stringProperty");
>
JTextField??? Ok. I've been doing too much swing lately. Hopefully,
you know that I ment TextField and not JTextField. Sadly, the models in
Swing are *much* more complicated and are not generified (as the
components are not).
--
Philip A. Chapman
Desktop and Web Application Development:
Java, .NET, PostgreSQL, MySQL, MSSQL
Linux, Windows 2000, Windows XP
Re: generics in Wicket
Posted by "Philip A. Chapman" <pc...@pcsw.us>.
Ryan,
I do not use property models much, so that's part of the difference
between our points of view (our coding styles). However, I do have at
least one page that uses one. In that case, I forgo generics. I define
raw types and set @SuppressWarnings("unchecked") on the methods that
access them:
JTextField tf = new JTextField(this, "stringProperty");
I would like to make the point that when I do use PropertyModels, I
usually throw away my component anyway (I don't usually assign it to a
variable) because I only really care about the Model and the data in it
anyway. The above code snippet was just an example.
The @SuppressWarnings annotation tells the compiler to shut up and not
bother me about it 'cause I know what I'm doing. The case that I
alluded to and Ivan asked about specifically is "What about those
components where generics really does matter?" Two components that he
suggested really need generics are DropDownChoice and ListView. There
are others, but this raises a point. I think that the problem that the
wicket devs ran into early on is that either all components are
generified or none (because of the models).
I think that my statement before is still a valid and is strengthened
above. If generic components are not appropriate for the code that you
are writing, don't use them. It's OK. It's better for you to have a
torx screwdriver in our common toolbox that you seldom use than to throw
it out and I have non, but need it daily.
Thanks,
On Mon, 2007-03-19 at 22:03 -0700, Ryan Holmes wrote:
> It's not that I don't like generics -- I just don't think Component
> makes sense as a generic class because it seems like the majority of
> use cases don't call for specifying a model type.
>
> Let me ask you, do you specify the type for form components even when
> you're using a CompoundPropertyModel (i.e. when you're never going to
> call getModel() or getModelObject() directly on those components)?
>
> And what about MarkupContainers and other components that you usually
> don't assign a model to?
>
> -Ryan
>
>
> On Mar 19, 2007, at 11:25 AM, Philip A. Chapman wrote:
>
> > 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
> >> <ee...@gmail.com> 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 <ry...@hyperstep.com> 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
>
--
Philip A. Chapman
Desktop and Web Application Development:
Java, .NET, PostgreSQL, MySQL, MSSQL
Linux, Windows 2000, Windows XP
Re: generics in Wicket
Posted by Ryan Holmes <ry...@hyperstep.com>.
I'm not sure what IModel<T> is for in that ListView constructor, but
the IModel<List<T>> is nice.
About the DropDownChoice, while the clarity is improved there as
well, that constructor prevents superclass/subclass type combinations
that should be legal.
For example, given the canonical Employee and Manager classes where
Manager is a subclass of Employee, the following code won't compile:
// Service method that returns only managers
public List<Manager> getManagers() {
...
}
// An entity object that holds an employee reference
public class Company {
private Employee employee;
public Employee getEmployee() {
return this.employee;
}
}
// DropDownChoice declaration that won't compile
public void test() {
Company company = new Company();
Model<List<Manager>> managers = new Model<List<Manager>>(getManagers
());
DropDownChoice<Employee> choice = new DropDownChoice<Employee>("id",
new Model<Employee>(company.getEmployee()), managers, new
ChoiceRenderer<Employee>());
}
I don't think this example is too unusual. The types could be
dictated by existing code: the service method returns a specific
subclass and the entity takes a superclass. We have a lot of
combinations like this because we have some pretty deep class
hierarchies.
Another problem would be a DropDownChoice<Manager> with a
ChoiceRenderer<Employee>, which again doesn't seem too unusual (and
we have that situation as well).
Unless my generics-fu is simply not up to snuff, it looks like there
could be some real technical issues with generic components in
addition to readability and productivity problems with all the time
and characters spent declaring types.
This is kind of half-assed, but I think the same level of clarity
improvement in those constructors could be achieved with:
ListView(String,IModel,IModel<List>)
and
DropDownChoice(String,IModel,IModel<List>,IChoiceRenderer)
-Ryan
On Mar 19, 2007, at 10:21 PM, Igor Vaynberg wrote:
> what about the cases where it is very nice to have?
>
> ListView(String,IModel<T>,IModel<List<T>>)
>
> or
>
> DropDownChoice(String,IModel<T>,IModel<List<T>>,IChoiceRenderer<T>)
>
> im not arguing for or against, but there are cases where it is very
> nice to
> have them, especially for newbies. when a newbie looks at the above
> they
> know whats going on as opposed to
>
> DropDownChoice(String,IModel,IModel,IChoiceRenderer)
>
> -igor
>
>
Re: generics in Wicket
Posted by Igor Vaynberg <ig...@gmail.com>.
what about the cases where it is very nice to have?
ListView(String,IModel<T>,IModel<List<T>>)
or
DropDownChoice(String,IModel<T>,IModel<List<T>>,IChoiceRenderer<T>)
im not arguing for or against, but there are cases where it is very nice to
have them, especially for newbies. when a newbie looks at the above they
know whats going on as opposed to
DropDownChoice(String,IModel,IModel,IChoiceRenderer)
-igor
On 3/19/07, Ryan Holmes <ry...@hyperstep.com> wrote:
>
> It's not that I don't like generics -- I just don't think Component
> makes sense as a generic class because it seems like the majority of
> use cases don't call for specifying a model type.
>
> Let me ask you, do you specify the type for form components even when
> you're using a CompoundPropertyModel (i.e. when you're never going to
> call getModel() or getModelObject() directly on those components)?
>
> And what about MarkupContainers and other components that you usually
> don't assign a model to?
>
> -Ryan
>
>
> On Mar 19, 2007, at 11:25 AM, Philip A. Chapman wrote:
>
> > 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
> >> <ee...@gmail.com> 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 <ry...@hyperstep.com> 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
>
>
Re: generics in Wicket
Posted by Ryan Holmes <ry...@hyperstep.com>.
It's not that I don't like generics -- I just don't think Component
makes sense as a generic class because it seems like the majority of
use cases don't call for specifying a model type.
Let me ask you, do you specify the type for form components even when
you're using a CompoundPropertyModel (i.e. when you're never going to
call getModel() or getModelObject() directly on those components)?
And what about MarkupContainers and other components that you usually
don't assign a model to?
-Ryan
On Mar 19, 2007, at 11:25 AM, Philip A. Chapman wrote:
> 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
>> <ee...@gmail.com> 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 <ry...@hyperstep.com> 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
AW: generics in Wicket
Posted by Korbinian Bachl <ko...@whiskyworld.de>.
BIG +1 from me on this post!
especially as everyone can set his compiler to ignore the generics when he
dont want them while they save much time for devs that use them
Regards
_____
Von: Philip A. Chapman [mailto:pchapman@pcsw.us]
Gesendet: Montag, 19. März 2007 19:26
An: wicket-dev@incubator.apache.org
Betreff: 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 <ee...@gmail.com> 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 <ry...@hyperstep.com> 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
Re: generics in Wicket
Posted by "Philip A. Chapman" <pc...@pcsw.us>.
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 <ee...@gmail.com> 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 <ry...@hyperstep.com> 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
AW: generics in Wicket
Posted by Stefan Lindner <li...@visionet.de>.
In our applications, most components benefit from being generic. Even a Markupcontainer with custom components is used generic.
Stefan Lindner
________________________________
Von: Ryan Holmes [mailto:ryan@hyperstep.com]
Gesendet: Di 20.03.2007 08:56
An: wicket-dev@incubator.apache.org
Betreff: Re: generics in Wicket
On Mar 20, 2007, at 12:35 AM, Stefan Lindner wrote:
> So the component developert must be very disciplined because the
> local variable "model" ist not generic. You can assign whatever
> IModel you want to the local "model". And the "return this.model"
> line will cause a warning.
The "return this.model" line is in the framework. The 2.0 code base
is full of raw references to components which also cause warnings/
unchecked casts, so I don't think that's an issue. No argument on
your bigger point that what I wrote below doesn't enforce type safety
inside the component.
>
> In most cases it makes sense to have Generic components.
But that's what I'm having a hard time with (and maybe it's just
because I haven't used 2.0) -- it seems like the majority of
component instances don't benefit from being generic. You obviously
use and like generic components quite a bit, so maybe you can give me
some perspective. These are essentially the same questions I asked
Philip:
When you have a form with a CompoundPropertyModel, do you still
declare the type of the form components and, if so, why?
What about MarkupContainer components that you don't specify a model
for?
-Ryan
>
> Stefan Lindner
>
> ________________________________
>
> Von: Ryan Holmes [mailto:ryan@hyperstep.com]
> Gesendet: Di 20.03.2007 07:58
> An: wicket-dev@incubator.apache.org
> Betreff: Re: generics in Wicket
>
>
>
>
> On Mar 19, 2007, at 12:58 AM, Eelco Hillenius wrote:
>>
>> Do you have an idea that works without having to generify Component?
>>
>
> Not sure if you would put this in the "idea that works" category, but
> I was thinking of something like this:
>
> public class Component {
> private IModel model;
>
> public <T> Component(final String id, final IModel<T> model) {
> this.model = model;
> }
>
> public <T> IModel<T> getModel() {
> return this.model;
> }
>
> public <T> void setModel(IModel<T> model) {
> this.model = model;
> }
> }
>
> This accommodates generic models but doesn't enforce type consistency
> between getModel and setModel. In practice, the types would usually
> be inferred:
>
> IModel<Integer> model = component.getModel();
>
> so it's easy to use and does eliminate casting, but get/set model
> inconsistency would only be caught at runtime (unless you use the
> full generic method syntax with a type parameter)
>
> I don't know -- it doesn't really buy you much. This doesn't work:
>
> Integer i = component.getModel().getObject();
>
> I also played around with the idea of a generic "ModelHolder" object
> inside of Component so at least getModel() and setModel() would use
> the same type parameter, but again the get/set model methods on
> Component itself can't pick that type up.
>
> <sigh> Oh well, maybe it's just taking me longer to come to the same
> conclusion you did.
>
> -Ryan
>
>
>
Re: generics in Wicket
Posted by Ryan Holmes <ry...@hyperstep.com>.
On Mar 20, 2007, at 12:35 AM, Stefan Lindner wrote:
> So the component developert must be very disciplined because the
> local variable "model" ist not generic. You can assign whatever
> IModel you want to the local "model". And the "return this.model"
> line will cause a warning.
The "return this.model" line is in the framework. The 2.0 code base
is full of raw references to components which also cause warnings/
unchecked casts, so I don't think that's an issue. No argument on
your bigger point that what I wrote below doesn't enforce type safety
inside the component.
>
> In most cases it makes sense to have Generic components.
But that's what I'm having a hard time with (and maybe it's just
because I haven't used 2.0) -- it seems like the majority of
component instances don't benefit from being generic. You obviously
use and like generic components quite a bit, so maybe you can give me
some perspective. These are essentially the same questions I asked
Philip:
When you have a form with a CompoundPropertyModel, do you still
declare the type of the form components and, if so, why?
What about MarkupContainer components that you don't specify a model
for?
-Ryan
>
> Stefan Lindner
>
> ________________________________
>
> Von: Ryan Holmes [mailto:ryan@hyperstep.com]
> Gesendet: Di 20.03.2007 07:58
> An: wicket-dev@incubator.apache.org
> Betreff: Re: generics in Wicket
>
>
>
>
> On Mar 19, 2007, at 12:58 AM, Eelco Hillenius wrote:
>>
>> Do you have an idea that works without having to generify Component?
>>
>
> Not sure if you would put this in the "idea that works" category, but
> I was thinking of something like this:
>
> public class Component {
> private IModel model;
>
> public <T> Component(final String id, final IModel<T> model) {
> this.model = model;
> }
>
> public <T> IModel<T> getModel() {
> return this.model;
> }
>
> public <T> void setModel(IModel<T> model) {
> this.model = model;
> }
> }
>
> This accommodates generic models but doesn't enforce type consistency
> between getModel and setModel. In practice, the types would usually
> be inferred:
>
> IModel<Integer> model = component.getModel();
>
> so it's easy to use and does eliminate casting, but get/set model
> inconsistency would only be caught at runtime (unless you use the
> full generic method syntax with a type parameter)
>
> I don't know -- it doesn't really buy you much. This doesn't work:
>
> Integer i = component.getModel().getObject();
>
> I also played around with the idea of a generic "ModelHolder" object
> inside of Component so at least getModel() and setModel() would use
> the same type parameter, but again the get/set model methods on
> Component itself can't pick that type up.
>
> <sigh> Oh well, maybe it's just taking me longer to come to the same
> conclusion you did.
>
> -Ryan
>
>
>
RE: generics in Wicket
Posted by Stefan Lindner <li...@visionet.de>.
So the component developert must be very disciplined because the local variable "model" ist not generic. You can assign whatever IModel you want to the local "model". And the "return this.model" line will cause a warning.
In most cases it makes sense to have Generic components.
Stefan Lindner
________________________________
Von: Ryan Holmes [mailto:ryan@hyperstep.com]
Gesendet: Di 20.03.2007 07:58
An: wicket-dev@incubator.apache.org
Betreff: Re: generics in Wicket
On Mar 19, 2007, at 12:58 AM, Eelco Hillenius wrote:
>
> Do you have an idea that works without having to generify Component?
>
Not sure if you would put this in the "idea that works" category, but
I was thinking of something like this:
public class Component {
private IModel model;
public <T> Component(final String id, final IModel<T> model) {
this.model = model;
}
public <T> IModel<T> getModel() {
return this.model;
}
public <T> void setModel(IModel<T> model) {
this.model = model;
}
}
This accommodates generic models but doesn't enforce type consistency
between getModel and setModel. In practice, the types would usually
be inferred:
IModel<Integer> model = component.getModel();
so it's easy to use and does eliminate casting, but get/set model
inconsistency would only be caught at runtime (unless you use the
full generic method syntax with a type parameter)
I don't know -- it doesn't really buy you much. This doesn't work:
Integer i = component.getModel().getObject();
I also played around with the idea of a generic "ModelHolder" object
inside of Component so at least getModel() and setModel() would use
the same type parameter, but again the get/set model methods on
Component itself can't pick that type up.
<sigh> Oh well, maybe it's just taking me longer to come to the same
conclusion you did.
-Ryan
Re: generics in Wicket
Posted by Ryan Holmes <ry...@hyperstep.com>.
On Mar 19, 2007, at 12:58 AM, Eelco Hillenius wrote:
>
> Do you have an idea that works without having to generify Component?
>
Not sure if you would put this in the "idea that works" category, but
I was thinking of something like this:
public class Component {
private IModel model;
public <T> Component(final String id, final IModel<T> model) {
this.model = model;
}
public <T> IModel<T> getModel() {
return this.model;
}
public <T> void setModel(IModel<T> model) {
this.model = model;
}
}
This accommodates generic models but doesn't enforce type consistency
between getModel and setModel. In practice, the types would usually
be inferred:
IModel<Integer> model = component.getModel();
so it's easy to use and does eliminate casting, but get/set model
inconsistency would only be caught at runtime (unless you use the
full generic method syntax with a type parameter)
I don't know -- it doesn't really buy you much. This doesn't work:
Integer i = component.getModel().getObject();
I also played around with the idea of a generic "ModelHolder" object
inside of Component so at least getModel() and setModel() would use
the same type parameter, but again the get/set model methods on
Component itself can't pick that type up.
<sigh> Oh well, maybe it's just taking me longer to come to the same
conclusion you did.
-Ryan
Re: generics in Wicket
Posted by Eelco Hillenius <ee...@gmail.com>.
> 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
Posted by Ryan Holmes <ry...@hyperstep.com>.
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 <ee...@gmail.com> 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 <ry...@hyperstep.com> 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
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <ee...@gmail.com> 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 <ry...@hyperstep.com> 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
Posted by Eelco Hillenius <ee...@gmail.com>.
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 <ry...@hyperstep.com> 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
Posted by Johan Compagner <jc...@gmail.com>.
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 <ry...@hyperstep.com> 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
Posted by Ryan Holmes <ry...@hyperstep.com>.
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
Posted by Eelco Hillenius <ee...@gmail.com>.
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 <li...@visionet.de> 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
>
>
RE: generics in Wicket
Posted by Jan Vermeulen <ja...@isencia.com>.
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.
--
View this message in context: http://www.nabble.com/generics-in-Wicket-tf3360271.html#a9360723
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [Vote] generics in Wicket
Posted by Jonathan Locke <jo...@gmail.com>.
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 <jo...@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.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/generics-in-Wicket-tf3360271.html#a9358451
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: generics in Wicket
Posted by Johan Compagner <jc...@gmail.com>.
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 <jo...@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
Posted by Jonathan Locke <jo...@gmail.com>.
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
Posted by Johan Compagner <jc...@gmail.com>.
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 <li...@visionet.de> 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
>
>
RE: generics in Wicket
Posted by Stefan Lindner <li...@visionet.de>.
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
RE: generics in Wicket
Posted by Jonathan Locke <jo...@gmail.com>.
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
>
>
--
View this message in context: http://www.nabble.com/generics-in-Wicket-tf3360271.html#a9354095
Sent from the Wicket - Dev mailing list archive at Nabble.com.
RE: generics in Wicket
Posted by Stefan Lindner <li...@visionet.de>.
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
Re: generics in Wicket
Posted by Johan Compagner <jc...@gmail.com>.
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 <ig...@gmail.com> 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 <ee...@gmail.com> 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 <ig...@gmail.com> 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 <ee...@gmail.com> 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
Posted by Johan Compagner <jc...@gmail.com>.
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 <ee...@gmail.com> wrote:
>
> On 3/7/07, Igor Vaynberg <ig...@gmail.com> 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
Posted by Igor Vaynberg <ig...@gmail.com>.
yes, but i figured johan was going to keep working on it instead of
backporting new features :)
-igor
On 3/7/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> On 3/7/07, Igor Vaynberg <ig...@gmail.com> 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
Posted by Eelco Hillenius <ee...@gmail.com>.
On 3/7/07, Igor Vaynberg <ig...@gmail.com> 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
Posted by Eelco Hillenius <ee...@gmail.com>.
On 3/7/07, Sven Meier <sv...@meiers.net> 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
Posted by Johan Compagner <jc...@gmail.com>.
Sven+++!
and no i will not use it as an excuse!
On 3/7/07, Sven Meier <sv...@meiers.net> 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 <ee...@gmail.com> 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 <ig...@gmail.com> 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 <ee...@gmail.com> 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
Posted by Sven Meier <sv...@meiers.net>.
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 <ee...@gmail.com> 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 <ig...@gmail.com> 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 <ee...@gmail.com> 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
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <ee...@gmail.com> 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 <ig...@gmail.com> 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 <ee...@gmail.com> 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
Posted by Eelco Hillenius <ee...@gmail.com>.
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 <ig...@gmail.com> 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 <ee...@gmail.com> 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
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <ee...@gmail.com> 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
Posted by Eelco Hillenius <ee...@gmail.com>.
> 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
Posted by Eelco Hillenius <ee...@gmail.com>.
> 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
Re: generics in Wicket
Posted by Johan Compagner <jc...@gmail.com>.
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 <ig...@gmail.com> 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 <ee...@gmail.com> 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
> >
>
Re: generics in Wicket
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <ee...@gmail.com> 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
>
Re: generics in Wicket
Posted by Eelco Hillenius <ee...@gmail.com>.
> 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
Re: generics in Wicket
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <ma...@gmail.com> 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 <ee...@gmail.com> 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
>
Re: generics in Wicket
Posted by Eelco Hillenius <ee...@gmail.com>.
> 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
Re: generics in Wicket
Posted by Martijn Dashorst <ma...@gmail.com>.
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 <ee...@gmail.com> 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
Re: generics in Wicket
Posted by Eelco Hillenius <ee...@gmail.com>.
> 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
Re: generics in Wicket
Posted by Johan Compagner <jc...@gmail.com>.
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 <ee...@gmail.com> 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
>
Re: generics in Wicket
Posted by Eelco Hillenius <ee...@gmail.com>.
> 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
Re: generics in Wicket
Posted by Patrick Angeles <pa...@inertiabev.com>.
Yea... come to think of it... the generic type gets erased at runtime.
Eelco Hillenius wrote:
>
> I don't think it is. Limitation of how generics work I'm afraid.
>
> Eelco
>
> On 3/20/07, Patrick Angeles <pa...@inertiabev.com> wrote:
>>
>>
>> Johan Compagner wrote:
>> >
>> > 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);
>> >
>>
>> I haven't looked at Wicket 2.0 source, so I may be off here, but it's
>> possible to skip the last parameter of the TextField constructor so it
>> looks
>> like this:
>>
>> TextField<Integer> integerTextField = new
>> TextField<Integer>(this,"integerProperty") ;
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/generics-in-Wicket-tf3360271.html#a9580850
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/generics-in-Wicket-tf3360271.html#a9581986
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: generics in Wicket
Posted by Eelco Hillenius <ee...@gmail.com>.
I don't think it is. Limitation of how generics work I'm afraid.
Eelco
On 3/20/07, Patrick Angeles <pa...@inertiabev.com> wrote:
>
>
> Johan Compagner wrote:
> >
> > 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);
> >
>
> I haven't looked at Wicket 2.0 source, so I may be off here, but it's
> possible to skip the last parameter of the TextField constructor so it looks
> like this:
>
> TextField<Integer> integerTextField = new
> TextField<Integer>(this,"integerProperty") ;
>
>
> --
> View this message in context: http://www.nabble.com/generics-in-Wicket-tf3360271.html#a9580850
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: generics in Wicket
Posted by Patrick Angeles <pa...@inertiabev.com>.
Johan Compagner wrote:
>
> 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);
>
I haven't looked at Wicket 2.0 source, so I may be off here, but it's
possible to skip the last parameter of the TextField constructor so it looks
like this:
TextField<Integer> integerTextField = new
TextField<Integer>(this,"integerProperty") ;
--
View this message in context: http://www.nabble.com/generics-in-Wicket-tf3360271.html#a9580850
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: generics in Wicket
Posted by Johan Compagner <jc...@gmail.com>.
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 <ee...@gmail.com> 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
>