generics

[Matej Knopp]

There is one thing that helped me quite a lot when migration the
project I'm working out. I've created GenericPanel,
GenericWebMarkupContainer and GenericFragment classes. In most cases
the only change was renaming Panel<MyClass> to GenericPanel<MyClass>.

I was wondering, even though those classes were farily simple, we
might want to include them in Wicket anyway, for the sake of
consistency and convenience.

-Matej

On Mon, Jun 30, 2008 at 12:28 PM, Johan Compagner <jcompagner@...> wrote:

> i looked through the code and it is fine by me.
> Lets test this then in a Build and see what people think of this.
>
>
> On Mon, Jun 30, 2008 at 8:54 AM, Igor Vaynberg <igor.vaynberg@...>
> wrote:
>
>> unit tests are fixed...
>>
>> -igor
>>
>> On Sun, Jun 29, 2008 at 11:16 PM, Martijn Dashorst
>> <martijn.dashorst@...> wrote:
>> > I'm guessing somewhere this week or so. We need to flush out the unit
>> > test failures and get some preliminary feedback. Also we need to have
>> > time available to actually build the release.
>> >
>> > My time is limited because we're in the final stages before publishing
>> > and I have to read our book twice or so.
>> >
>> > Martijn
>> >
>> > On Mon, Jun 30, 2008 at 2:36 AM, James Carman
>> > <james@...> wrote:
>> >> What sort of time frame are we looking at for a release with this new
>> >> generics paradigm?
>> >>
>> >> On Sun, Jun 29, 2008 at 3:54 PM, Igor Vaynberg <igor.vaynberg@...>
>> wrote:
>> >>> On Sun, Jun 29, 2008 at 12:48 PM, Sven Meier <sven@...> wrote:
>> >>>> Hi,
>> >>>>
>> >>>> I've just converted two projects to the new generics setup and
>> everything
>> >>>> worked out nicely.
>> >>>> I think this is how generics should be applied to Wicket.
>> >>>>
>> >>>> Igor, thanks for your hard work on this.
>> >>>
>> >>> wasnt just me :)
>> >>>
>> >>> -igor
>> >>>
>> >>>>
>> >>>> Sven
>> >>>>
>> >>>> Igor Vaynberg schrieb:
>> >>>>>
>> >>>>> development of the 1.4 branch has been quiet lately, this is because
>> >>>>> the core team has been busy working on an alternative way of
>> >>>>> generifiing the framework. an early result of that effort can be
>> found
>> >>>>> here [1]. The key difference in [1] is that we have decoupled the
>> >>>>> component from the type of the model.
>> >>>>>
>> >>>>> here is the list of major differences:
>> >>>>>
>> >>>>> (1) only components that use their model have a generic type
>> >>>>> (components you are likely to call getmodel/getmodelobject on as a
>> >>>>> user). so far these are link,form,formcomponent
>> >>>>> subclasses,listview,listitem,(other repeaters will follow soon). this
>> >>>>> allows for typesafety where it makes sense, and eliminates a ton of
>> >>>>> noise from code. we will generify others upon request if a good
>> >>>>> usecase is provided and we think it is widely applicable.
>> >>>>>
>> >>>>> (2) non-generified components do not have IModel<T> get/setModel and
>> T
>> >>>>> get/setModelObject, instead they have IModel<?>get/setDefaultModel
>> and
>> >>>>> Object get/setDefaultModelObject. this clearly expresses that the
>> >>>>> default component model is not tied to the type of component. this is
>> >>>>> a bit of a pain from the code migration point of view, but we think
>> is
>> >>>>> worth the effort. generifyed components are free to implement the old
>> >>>>> IModel<T> get/setModel, etc, but have to keep the unsafe cast inside.
>> >>>>> see ListItem for an example.
>> >>>>>
>> >>>>> basically we feel this is a much cleaner way then what is 1.4m2. this
>> >>>>> is a call for confirmation/discussion from our user base. do try to
>> >>>>> port a small project or a part of a larger project you are working on
>> >>>>> to the [1] branch to see how the new api feels. if we do like this
>> >>>>> more the new branch will be merged into what will be 1.4m3.
>> >>>>>
>> >>>>> [1]
>> https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/generics
>> >>>>>
>> >>>>> -igor
>> >>>>>
>> >>>>> ---------------------------------------------------------------------
>> >>>>> To unsubscribe, e-mail: users-unsubscribe@...
>> >>>>> For additional commands, e-mail: users-help@...
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: users-unsubscribe@...
>> >>>> For additional commands, e-mail: users-help@...
>> >>>>
>> >>>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@...
>> >>> For additional commands, e-mail: users-help@...
>> >>>
>> >>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@...
>> >> For additional commands, e-mail: users-help@...
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Become a Wicket expert, learn from the best: http://wicketinaction.com
>> > Apache Wicket 1.3.4 is released
>> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@...
>> > For additional commands, e-mail: users-help@...
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>

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

[Patrick Angeles]

I second Matej here... maybe instead of GenericPanel<T>, GenericFragment<T>, etc. you could name it something more explicit. Some examples:

SingleModelPanel<T>
ModelBoundPanel<T>

It took me the better part of one day to convert a partially genericized project (we started out with 1.3 then switched to 1.4 mid-stream). The project had 100k++ LOC. The resulting code is much easier to read.

Another thing that you can consider adding to the core... a utilities class 'Models' to wrap models so you don't have those pesky <> all over the place:

public MyPanel(String id, IModel<Integer> model)
{
   super (id, Models.compound (model)); // wrap model in a CompoundPropertyModel
}

Matej Knopp-2 wrote:

There is one thing that helped me quite a lot when migration the
project I'm working out. I've created GenericPanel,
GenericWebMarkupContainer and GenericFragment classes. In most cases
the only change was renaming Panel<MyClass> to GenericPanel<MyClass>.

I was wondering, even though those classes were farily simple, we
might want to include them in Wicket anyway, for the sake of
consistency and convenience.

-Matej

On Mon, Jun 30, 2008 at 12:28 PM, Johan Compagner <[e-mail]> wrote:
> i looked through the code and it is fine by me.
> Lets test this then in a Build and see what people think of this.
>
>
> On Mon, Jun 30, 2008 at 8:54 AM, Igor Vaynberg <[e-mail]>
> wrote:
>
>> unit tests are fixed...
>>
>> -igor
>>
>> On Sun, Jun 29, 2008 at 11:16 PM, Martijn Dashorst
>> <[e-mail]> wrote:
>> > I'm guessing somewhere this week or so. We need to flush out the unit
>> > test failures and get some preliminary feedback. Also we need to have
>> > time available to actually build the release.
>> >
>> > My time is limited because we're in the final stages before publishing
>> > and I have to read our book twice or so.
>> >
>> > Martijn
>> >
>> > On Mon, Jun 30, 2008 at 2:36 AM, James Carman
>> > <[e-mail]> wrote:
>> >> What sort of time frame are we looking at for a release with this new
>> >> generics paradigm?
>> >>
>> >> On Sun, Jun 29, 2008 at 3:54 PM, Igor Vaynberg <[e-mail]>
>> wrote:
>> >>> On Sun, Jun 29, 2008 at 12:48 PM, Sven Meier <[e-mail]> wrote:
>> >>>> Hi,
>> >>>>
>> >>>> I've just converted two projects to the new generics setup and
>> everything
>> >>>> worked out nicely.
>> >>>> I think this is how generics should be applied to Wicket.
>> >>>>
>> >>>> Igor, thanks for your hard work on this.
>> >>>
>> >>> wasnt just me :)
>> >>>
>> >>> -igor
>> >>>
>> >>>>
>> >>>> Sven
>> >>>>
>> >>>> Igor Vaynberg schrieb:
>> >>>>>
>> >>>>> development of the 1.4 branch has been quiet lately, this is because
>> >>>>> the core team has been busy working on an alternative way of
>> >>>>> generifiing the framework. an early result of that effort can be
>> found
>> >>>>> here [1]. The key difference in [1] is that we have decoupled the
>> >>>>> component from the type of the model.
>> >>>>>
>> >>>>> here is the list of major differences:
>> >>>>>
>> >>>>> (1) only components that use their model have a generic type
>> >>>>> (components you are likely to call getmodel/getmodelobject on as a
>> >>>>> user). so far these are link,form,formcomponent
>> >>>>> subclasses,listview,listitem,(other repeaters will follow soon). this
>> >>>>> allows for typesafety where it makes sense, and eliminates a ton of
>> >>>>> noise from code. we will generify others upon request if a good
>> >>>>> usecase is provided and we think it is widely applicable.
>> >>>>>
>> >>>>> (2) non-generified components do not have IModel<T> get/setModel and
>> T
>> >>>>> get/setModelObject, instead they have IModel<?>get/setDefaultModel
>> and
>> >>>>> Object get/setDefaultModelObject. this clearly expresses that the
>> >>>>> default component model is not tied to the type of component. this is
>> >>>>> a bit of a pain from the code migration point of view, but we think
>> is
>> >>>>> worth the effort. generifyed components are free to implement the old
>> >>>>> IModel<T> get/setModel, etc, but have to keep the unsafe cast inside.
>> >>>>> see ListItem for an example.
>> >>>>>
>> >>>>> basically we feel this is a much cleaner way then what is 1.4m2. this
>> >>>>> is a call for confirmation/discussion from our user base. do try to
>> >>>>> port a small project or a part of a larger project you are working on
>> >>>>> to the [1] branch to see how the new api feels. if we do like this
>> >>>>> more the new branch will be merged into what will be 1.4m3.
>> >>>>>
>> >>>>> [1]
>> https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/generics
>> >>>>>
>> >>>>> -igor
>> >>>>>
>> >>>>> ---------------------------------------------------------------------
>> >>>>> To unsubscribe, e-mail: [e-mail]
>> >>>>> For additional commands, e-mail: [e-mail]
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: [e-mail]
>> >>>> For additional commands, e-mail: [e-mail]
>> >>>>
>> >>>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: [e-mail]
>> >>> For additional commands, e-mail: [e-mail]
>> >>>
>> >>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [e-mail]
>> >> For additional commands, e-mail: [e-mail]
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Become a Wicket expert, learn from the best: http://wicketinaction.com
>> > Apache Wicket 1.3.4 is released
>> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [e-mail]
>> > For additional commands, e-mail: [e-mail]
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [e-mail]
>> For additional commands, e-mail: [e-mail]
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]

[Rodolfo Hansen-2]

I too like this compromise alot

Although I don't see a good use case for generifying Link ?
Am I missing something?


On Fri, Jun 27, 2008 at 2:49 PM, Timo Rantalaiho <Timo.Rantalaiho@...>
wrote:

> On Fri, 27 Jun 2008, Igor Vaynberg wrote:
> > since no one complained, should we apply this change over the weekend?
> > and soon thereafter release m3?
>
> I prefer this over M2. Even though:
>
> > > user). so far these are link,form,formcomponent
>
> Link might be better without the type parameter. It's no big
> deal though.
>
> And yes, it would be good if for example Johan and Gerolf
> who have invested a lot of effort on the generification
> could have a closer look and tell what they think before
> proceeding.
>
> Best wishes,
> Timo
>
> --
> Timo Rantalaiho
> Reaktor Innovations Oy    <URL: http://www.ri.fi/ >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[igor.vaynberg]

onPopulateItem(Item<User> item) {
  add(new Link<User>("delete", item.getModel()) {
       protected void onClick() { service.delete(getModelObject()); }
  });
}

-igor

On Tue, Jul 1, 2008 at 11:51 AM, Rodolfo Hansen <rhansen@...> wrote:

> I too like this compromise alot
>
> Although I don't see a good use case for generifying Link ?
> Am I missing something?
>
>
> On Fri, Jun 27, 2008 at 2:49 PM, Timo Rantalaiho <Timo.Rantalaiho@...>
> wrote:
>
>> On Fri, 27 Jun 2008, Igor Vaynberg wrote:
>> > since no one complained, should we apply this change over the weekend?
>> > and soon thereafter release m3?
>>
>> I prefer this over M2. Even though:
>>
>> > > user). so far these are link,form,formcomponent
>>
>> Link might be better without the type parameter. It's no big
>> deal though.
>>
>> And yes, it would be good if for example Johan and Gerolf
>> who have invested a lot of effort on the generification
>> could have a closer look and tell what they think before
>> proceeding.
>>
>> Best wishes,
>> Timo
>>
>> --
>> Timo Rantalaiho
>> Reaktor Innovations Oy    <URL: http://www.ri.fi/ >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>

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

[Patrick Angeles]

add (new Link<Person>("edit", person) {
  public void onClick () {
    setResponsePage (new EditPersonPage (getModel()));
  }
});

This code makes a lot more sense if it is inside a repeater...

Rodolfo Hansen-2 wrote:

I too like this compromise alot

Although I don't see a good use case for generifying Link ?
Am I missing something?


On Fri, Jun 27, 2008 at 2:49 PM, Timo Rantalaiho <[e-mail]>
wrote:

> On Fri, 27 Jun 2008, Igor Vaynberg wrote:
> > since no one complained, should we apply this change over the weekend?
> > and soon thereafter release m3?
>
> I prefer this over M2. Even though:
>
> > > user). so far these are link,form,formcomponent
>
> Link might be better without the type parameter. It's no big
> deal though.
>
> And yes, it would be good if for example Johan and Gerolf
> who have invested a lot of effort on the generification
> could have a closer look and tell what they think before
> proceeding.
>
> Best wishes,
> Timo
>
> --
> Timo Rantalaiho
> Reaktor Innovations Oy    <URL: http://www.ri.fi/ >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>

[Joni Freeman]

Isn't this a same thing:

onPopulateItem(final Item<User> item) {
  add(new Link("delete") {
    protected void onClick() { service.delete(item.getModelObject()); }
  });
}

Joni

On Tue, 2008-07-01 at 11:56 -0700, Igor Vaynberg wrote:

> onPopulateItem(Item<User> item) {
>   add(new Link<User>("delete", item.getModel()) {
>        protected void onClick() { service.delete(getModelObject()); }
>   });
> }
>
> -igor
>
> On Tue, Jul 1, 2008 at 11:51 AM, Rodolfo Hansen <rhansen@...> wrote:
> > I too like this compromise alot
> >
> > Although I don't see a good use case for generifying Link ?
> > Am I missing something?
> >
> >
> > On Fri, Jun 27, 2008 at 2:49 PM, Timo Rantalaiho <Timo.Rantalaiho@...>
> > wrote:
> >
> >> On Fri, 27 Jun 2008, Igor Vaynberg wrote:
> >> > since no one complained, should we apply this change over the weekend?
> >> > and soon thereafter release m3?
> >>
> >> I prefer this over M2. Even though:
> >>
> >> > > user). so far these are link,form,formcomponent
> >>
> >> Link might be better without the type parameter. It's no big
> >> deal though.
> >>
> >> And yes, it would be good if for example Johan and Gerolf
> >> who have invested a lot of effort on the generification
> >> could have a closer look and tell what they think before
> >> proceeding.
> >>
> >> Best wishes,
> >> Timo
> >>
> >> --
> >> Timo Rantalaiho
> >> Reaktor Innovations Oy    <URL: http://www.ri.fi/ >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@...
> >> For additional commands, e-mail: users-help@...
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

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

[igor.vaynberg]

if your link is anonymous, yes. if you have reusable links in their
own class, then no.

-igor

On Tue, Jul 1, 2008 at 12:24 PM, Joni Freeman <joni.freeman@...> wrote:

> Isn't this a same thing:
>
> onPopulateItem(final Item<User> item) {
>  add(new Link("delete") {
>    protected void onClick() { service.delete(item.getModelObject()); }
>  });
> }
>
> Joni
>
> On Tue, 2008-07-01 at 11:56 -0700, Igor Vaynberg wrote:
>> onPopulateItem(Item<User> item) {
>>   add(new Link<User>("delete", item.getModel()) {
>>        protected void onClick() { service.delete(getModelObject()); }
>>   });
>> }
>>
>> -igor
>>
>> On Tue, Jul 1, 2008 at 11:51 AM, Rodolfo Hansen <rhansen@...> wrote:
>> > I too like this compromise alot
>> >
>> > Although I don't see a good use case for generifying Link ?
>> > Am I missing something?
>> >
>> >
>> > On Fri, Jun 27, 2008 at 2:49 PM, Timo Rantalaiho <Timo.Rantalaiho@...>
>> > wrote:
>> >
>> >> On Fri, 27 Jun 2008, Igor Vaynberg wrote:
>> >> > since no one complained, should we apply this change over the weekend?
>> >> > and soon thereafter release m3?
>> >>
>> >> I prefer this over M2. Even though:
>> >>
>> >> > > user). so far these are link,form,formcomponent
>> >>
>> >> Link might be better without the type parameter. It's no big
>> >> deal though.
>> >>
>> >> And yes, it would be good if for example Johan and Gerolf
>> >> who have invested a lot of effort on the generification
>> >> could have a closer look and tell what they think before
>> >> proceeding.
>> >>
>> >> Best wishes,
>> >> Timo
>> >>
>> >> --
>> >> Timo Rantalaiho
>> >> Reaktor Innovations Oy    <URL: http://www.ri.fi/ >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@...
>> >> For additional commands, e-mail: users-help@...
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

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

[svenmeier]

Wouldn't it be better to leave the generic part to this reusable link
then? Why 'pollute' all links with a generic parameter?

Back to your definition:

>> (1) only components that use their model have a generic type
>> (components you are likely to call getmodel/getmodelobject on as a
>> user).

What now? Components that use their model *or* you're likely to call getmodel on? Seems to me as two different things:
Link doesn't fit in the first category nor is it always used with a model.

Sven

Igor Vaynberg schrieb:

> if your link is anonymous, yes. if you have reusable links in their
> own class, then no.
>
> -igor
>
> On Tue, Jul 1, 2008 at 12:24 PM, Joni Freeman <joni.freeman@...> wrote:
>  
>> Isn't this a same thing:
>>
>> onPopulateItem(final Item<User> item) {
>>  add(new Link("delete") {
>>    protected void onClick() { service.delete(item.getModelObject()); }
>>  });
>> }
>>
>> Joni
>>
>> On Tue, 2008-07-01 at 11:56 -0700, Igor Vaynberg wrote:
>>    
>>> onPopulateItem(Item<User> item) {
>>>   add(new Link<User>("delete", item.getModel()) {
>>>        protected void onClick() { service.delete(getModelObject()); }
>>>   });
>>> }
>>>
>>> -igor
>>>
>>> On Tue, Jul 1, 2008 at 11:51 AM, Rodolfo Hansen <rhansen@...> wrote:
>>>      
>>>> I too like this compromise alot
>>>>
>>>> Although I don't see a good use case for generifying Link ?
>>>> Am I missing something?
>>>>
>>>>
>>>> On Fri, Jun 27, 2008 at 2:49 PM, Timo Rantalaiho <Timo.Rantalaiho@...>
>>>> wrote:
>>>>
>>>>        
>>>>> On Fri, 27 Jun 2008, Igor Vaynberg wrote:
>>>>>          
>>>>>> since no one complained, should we apply this change over the weekend?
>>>>>> and soon thereafter release m3?
>>>>>>            
>>>>> I prefer this over M2. Even though:
>>>>>
>>>>>          
>>>>>>> user). so far these are link,form,formcomponent
>>>>>>>              
>>>>> Link might be better without the type parameter. It's no big
>>>>> deal though.
>>>>>
>>>>> And yes, it would be good if for example Johan and Gerolf
>>>>> who have invested a lot of effort on the generification
>>>>> could have a closer look and tell what they think before
>>>>> proceeding.
>>>>>
>>>>> Best wishes,
>>>>> Timo
>>>>>
>>>>> --
>>>>> Timo Rantalaiho
>>>>> Reaktor Innovations Oy    <URL: http://www.ri.fi/ >
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>>
>>>>>          
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>      
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>  

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

[igor.vaynberg]

the question here is: do most people use the model in the Link or not?

when you use compound property model in conjunction with form
components you never call getmodel/object() on those either. what now?
not generify form components? i dont think a strict criteria will
work.

some components fall into a gray area which needs to be discussed and
generified on case by case basis. when i was generifying wicket my
primary usecase is to use Link with a model so i went that way. start
a discussion/vote and see where that goes in a different thread. i
will be happy to go with what the majority thinks in this particular
case.

-igor

On Tue, Jul 1, 2008 at 2:34 PM, Sven Meier <sven@...> wrote:

> Wouldn't it be better to leave the generic part to this reusable link then?
> Why 'pollute' all links with a generic parameter?
>
> Back to your definition:
>
>>> (1) only components that use their model have a generic type
>>> (components you are likely to call getmodel/getmodelobject on as a
>>> user).
>
> What now? Components that use their model *or* you're likely to call
> getmodel on? Seems to me as two different things:
> Link doesn't fit in the first category nor is it always used with a model.
>
> Sven
>
> Igor Vaynberg schrieb:
>>
>> if your link is anonymous, yes. if you have reusable links in their
>> own class, then no.
>>
>> -igor
>>
>> On Tue, Jul 1, 2008 at 12:24 PM, Joni Freeman <joni.freeman@...> wrote:
>>
>>>
>>> Isn't this a same thing:
>>>
>>> onPopulateItem(final Item<User> item) {
>>>  add(new Link("delete") {
>>>   protected void onClick() { service.delete(item.getModelObject()); }
>>>  });
>>> }
>>>
>>> Joni
>>>
>>> On Tue, 2008-07-01 at 11:56 -0700, Igor Vaynberg wrote:
>>>
>>>>
>>>> onPopulateItem(Item<User> item) {
>>>>  add(new Link<User>("delete", item.getModel()) {
>>>>       protected void onClick() { service.delete(getModelObject()); }
>>>>  });
>>>> }
>>>>
>>>> -igor
>>>>
>>>> On Tue, Jul 1, 2008 at 11:51 AM, Rodolfo Hansen <rhansen@...>
>>>> wrote:
>>>>
>>>>>
>>>>> I too like this compromise alot
>>>>>
>>>>> Although I don't see a good use case for generifying Link ?
>>>>> Am I missing something?
>>>>>
>>>>>
>>>>> On Fri, Jun 27, 2008 at 2:49 PM, Timo Rantalaiho
>>>>> <Timo.Rantalaiho@...>
>>>>> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> On Fri, 27 Jun 2008, Igor Vaynberg wrote:
>>>>>>
>>>>>>>
>>>>>>> since no one complained, should we apply this change over the
>>>>>>> weekend?
>>>>>>> and soon thereafter release m3?
>>>>>>>
>>>>>>
>>>>>> I prefer this over M2. Even though:
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> user). so far these are link,form,formcomponent
>>>>>>>>
>>>>>>
>>>>>> Link might be better without the type parameter. It's no big
>>>>>> deal though.
>>>>>>
>>>>>> And yes, it would be good if for example Johan and Gerolf
>>>>>> who have invested a lot of effort on the generification
>>>>>> could have a closer look and tell what they think before
>>>>>> proceeding.
>>>>>>
>>>>>> Best wishes,
>>>>>> Timo
>>>>>>
>>>>>> --
>>>>>> Timo Rantalaiho
>>>>>> Reaktor Innovations Oy    <URL: http://www.ri.fi/ >
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>> For additional commands, e-mail: users-help@...
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

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

[Timo Rantalaiho]

On Tue, 01 Jul 2008, Matej Knopp wrote:
> There is one thing that helped me quite a lot when migration the
> project I'm working out. I've created GenericPanel,
> GenericWebMarkupContainer and GenericFragment classes. In most cases
> the only change was renaming Panel<MyClass> to GenericPanel<MyClass>.

Maybe the names could be TypedPanel / ModelContainingPanel
or something like that?

Or maybe start with the original component name so that they
would pop up more easily in the IDE, for example
PanelWithType / PanelWithModel?

> I was wondering, even though those classes were farily simple, we
> might want to include them in Wicket anyway, for the sake of
> consistency and convenience.

I thought about this and I think that it might be better to
not include them after all. In 1.5 it would be great to
separate IModel and Component more thoroughly, getting rid
of the defaultModel* accessors. Then it would make less
sense to have the convenience classes with those model and
modelObject accessors.

In cases where two components share the same model, it would
make sense to make the IModel field in each component final.
Then setModel() does not make sense any more; all it could
do would be throw an exception or be a confusing no-op.
Likewise, sometimes you never do setModelObject() or
getModelObject() from outside the class.

Leaner APIs and less methods per objects are good things.
Hence it's better to add methods as you need them, instead
of providing a lot of convenience stuff that is only used a
part of the time. Surely each Component subclass has anyway
a lot of methods, and MarkupContainers even more, but you
have got to start somewhere :)

This is not a big deal though, either way is fine by me.

Best wishes,
Timo

--
Timo Rantalaiho          
Reaktor Innovations Oy    <URL: http://www.ri.fi/ >

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

[Eelco Hillenius]

> This is not a big deal though, either way is fine by me.

I prefer link to be not generified, but either way is fine by me as well.

Eelco

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

[igor.vaynberg]

if we ungenerify Link, should we also ungenerify Form? seems like the
exact same kind of usecase.

-igor

On Tue, Jul 1, 2008 at 10:25 PM, Eelco Hillenius
<eelco.hillenius@...> wrote:

>> This is not a big deal though, either way is fine by me.
>
> I prefer link to be not generified, but either way is fine by me as well.
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

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

[Eelco Hillenius]

On Tue, Jul 1, 2008 at 11:09 PM, Igor Vaynberg <igor.vaynberg@...> wrote:
> if we ungenerify Link, should we also ungenerify Form? seems like the
> exact same kind of usecase.

Imho, generic forms make more sense, as you'd typically work on fields
(with formcomponents) of one object (the model object of the form),
and then do something with it if updating the fields succeeds (like
saving the changes). It is true that you often use some model value(s)
in the link onClick method, but personally I never do that through the
model value, but rather like how Timo described it.

Anyway, not a big deal really. If you feel Link is better generified,
I'm cool with it.

Eelco

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

[igor.vaynberg]

On Tue, Jul 1, 2008 at 11:28 PM, Eelco Hillenius
<eelco.hillenius@...> wrote:
> On Tue, Jul 1, 2008 at 11:09 PM, Igor Vaynberg <igor.vaynberg@...> wrote:
>> if we ungenerify Link, should we also ungenerify Form? seems like the
>> exact same kind of usecase.
>
> Imho, generic forms make more sense, as you'd typically work on fields
> (with formcomponents) of one object (the model object of the form)

thats my point. you work on fields of one object, true, but it does
not necessarily have to be the form's modelobject unless you use a
compound property model. eg

        Form<Void> form = new Form<Void>("form")
        {
            protected void onSubmit() { value = dosomethingwith(symbol); }
        };
        add(form);

        form.add(new TextField<String>("symbol", new
PropertyModel<String>(this, "symbol")));

where [value] and [symbol] are clearly fields on the container that
parents the form. inside onsubmit i can just as easily access the
object directly without it being the model object of the form. now if
we factor out the form into a static inner or a top level class, just
like the link discussion, it becomes valuable to have the model.

> Anyway, not a big deal really. If you feel Link is better generified,
> I'm cool with it.

i agree that its no big deal, i am just trying to figure out some sort
of guidelines for when we do include the type and when we dont. if we
say that we only include the type when the component uses its model
then neither Link nor Form qualify. in fact neither will ListItem.
only things like ListView and FormComponents will qualify.

-igor

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

[Eelco Hillenius]

> thats my point. you work on fields of one object, true, but it does
> not necessarily have to be the form's modelobject unless you use a
> compound property model. eg
>
>        Form<Void> form = new Form<Void>("form")
>        {
>            protected void onSubmit() { value = dosomethingwith(symbol); }
>        };
>        add(form);
>
>        form.add(new TextField<String>("symbol", new
> PropertyModel<String>(this, "symbol")));
>
> where [value] and [symbol] are clearly fields on the container that
> parents the form. inside onsubmit i can just as easily access the
> object directly without it being the model object of the form. now if
> we factor out the form into a static inner or a top level class, just
> like the link discussion, it becomes valuable to have the model.

Yeah, you're right actually. I realize now that I rarely use Form's
model directly. And I actually do the special stuff in the buttons
anyway.

Eelco

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

[Johan Compagner]

I still dont see a complete decoupling or do you mean only getDefaultXxxx()?
So all the getModel() (Link/FormComponent) are still there?

For link we could have Link (without model) and ModelLink (generified
and with get/setModel) that would be fine with me.

On 7/2/08, Timo Rantalaiho <Timo.Rantalaiho@...> wrote:

> On Tue, 01 Jul 2008, Matej Knopp wrote:
>> There is one thing that helped me quite a lot when migration the
>> project I'm working out. I've created GenericPanel,
>> GenericWebMarkupContainer and GenericFragment classes. In most cases
>> the only change was renaming Panel<MyClass> to GenericPanel<MyClass>.
>
> Maybe the names could be TypedPanel / ModelContainingPanel
> or something like that?
>
> Or maybe start with the original component name so that they
> would pop up more easily in the IDE, for example
> PanelWithType / PanelWithModel?
>
>> I was wondering, even though those classes were farily simple, we
>> might want to include them in Wicket anyway, for the sake of
>> consistency and convenience.
>
> I thought about this and I think that it might be better to
> not include them after all. In 1.5 it would be great to
> separate IModel and Component more thoroughly, getting rid
> of the defaultModel* accessors. Then it would make less
> sense to have the convenience classes with those model and
> modelObject accessors.
>
> In cases where two components share the same model, it would
> make sense to make the IModel field in each component final.
> Then setModel() does not make sense any more; all it could
> do would be throw an exception or be a confusing no-op.
> Likewise, sometimes you never do setModelObject() or
> getModelObject() from outside the class.
>
> Leaner APIs and less methods per objects are good things.
> Hence it's better to add methods as you need them, instead
> of providing a lot of convenience stuff that is only used a
> part of the time. Surely each Component subclass has anyway
> a lot of methods, and MarkupContainers even more, but you
> have got to start somewhere :)
>
> This is not a big deal though, either way is fine by me.
>
> Best wishes,
> Timo
>
> --
> Timo Rantalaiho
> Reaktor Innovations Oy    <URL: http://www.ri.fi/ >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

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

[Jan Kriesten]

Hi,

> i agree that its no big deal, i am just trying to figure out some sort
> of guidelines for when we do include the type and when we dont. if we
> say that we only include the type when the component uses its model
> then neither Link nor Form qualify. in fact neither will ListItem.
> only things like ListView and FormComponents will qualify.

I'd actually prefer untyped Link and Form, since I also don't use Models on them
directly most of the time. But other's may have a different style and always use
Models...

Best regards, --- Jan.

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

[Johan Compagner]

thats completely up how you use it
I can think of a lot that dont use models on FormComponents but only on
Forms
If you use CompoundModel then you never will touch or give a FormComponent a
model.
and all your stuff is done on the Model of the Form. (in the onSubmit for
example)

So this can never be generalized like this will never be used this way
The only way for this is to have a complete separate stack of
"ModelComponents/GenericComponents"

See for example Link, Igor says i use model a lot. Eelco says he never uses
it.. (but he uses it on button if i read correctly which is the same thing
as a link)

johan


On Wed, Jul 2, 2008 at 9:15 AM, Jan Kriesten <jan.kriesten@...>
wrote:

>
> Hi,
>
>  i agree that its no big deal, i am just trying to figure out some sort
>> of guidelines for when we do include the type and when we dont. if we
>> say that we only include the type when the component uses its model
>> then neither Link nor Form qualify. in fact neither will ListItem.
>> only things like ListView and FormComponents will qualify.
>>
>
> I'd actually prefer untyped Link and Form, since I also don't use Models on
> them directly most of the time. But other's may have a different style and
> always use Models...
>
> Best regards, --- Jan.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Roland Huss]

igor.vaynberg wrote:

On Tue, Jul 1, 2008 at 11:28 PM, Eelco Hillenius
<[e-mail]> wrote:
thats my point. you work on fields of one object, true, but it does
not necessarily have to be the form's modelobject unless you use a
compound property model.

The usage of a CompoundPropertyModel as a Form-model saved us quite some typing and it's IMO
a very common use case. In fact, this it propbably the most relevant use case for a CPM anyway.
So, I'm in favor of having a Form with Model (or at least a variation like a ModelForm<T> ...)

... roland

[Matej Knopp]

On Wed, Jul 2, 2008 at 4:28 AM, Timo Rantalaiho <Timo.Rantalaiho@...> wrote:
> On Tue, 01 Jul 2008, Matej Knopp wrote:
>> There is one thing that helped me quite a lot when migration the
>> project I'm working out. I've created GenericPanel,
>> GenericWebMarkupContainer and GenericFragment classes. In most cases
>> the only change was renaming Panel<MyClass> to GenericPanel<MyClass>.
>
> Maybe the names could be TypedPanel / ModelContainingPanel
> or something like that?
I still don't see what's wrong with GenericPanel. It's certainly much
easier to type than ModelContainingPanel.

>
> Or maybe start with the original component name so that they
> would pop up more easily in the IDE, for example
> PanelWithType / PanelWithModel?
>
>> I was wondering, even though those classes were farily simple, we
>> might want to include them in Wicket anyway, for the sake of
>> consistency and convenience.
>
> I thought about this and I think that it might be better to
> not include them after all. In 1.5 it would be great to
> separate IModel and Component more thoroughly, getting rid
> of the defaultModel* accessors. Then it would make less
> sense to have the convenience classes with those model and
> modelObject accessors.

I strongly disagree. There are good reasons for Wicket to bind model
and component together and I think what we have in 1.4 right now is a
balanced compromise. Also if we don't provide the convenience classes
people will bound to write their own (because it's the only reasonable
way to migrate project that already uses generics).

>
> In cases where two components share the same model, it would
> make sense to make the IModel field in each component final.
> Then setModel() does not make sense any more; all it could
> do would be throw an exception or be a confusing no-op.
> Likewise, sometimes you never do setModelObject() or
> getModelObject() from outside the class.

You don't have to use those methods, there are for convenience only.

>
> Leaner APIs and less methods per objects are good things.
> Hence it's better to add methods as you need them, instead
> of providing a lot of convenience stuff that is only used a
> part of the time. Surely each Component subclass has anyway
> a lot of methods, and MarkupContainers even more, but you
> have got to start somewhere :)

I don't buy this. Our components have a lot of methods, but most of
them are not part of public API. I plan to prefix those methods with a
common prefix for 1.5 so they don't confuse regular users. But I
really don't see how removing four methods (*defaultModel) improves
our api.

We will always need some kind of utility methods for manipulating
models in component.

Models have always been conceptually bound to component. Right now the
problem of our API is not that we have a model slot in component. It
is that we have exactly one model slot. This doesn't work well for all
components, since some don't need model at all and some need more than
one.

Unfortunately the component <-> model contract is quite complicated as
we have compound models, componentassignedmodels, etc so a simple
property for model doesn't really cut it. We still need some kind of
model manipuation methods. Something like current setDefaultModel,...
but more flexible. And when we do have it, having
GenericPanel,Fragment,... might make the migration for users lot
esier. Now thinking about it, the name should really suggest that
there is one model per component. Maybe PanelWithModel could be the
name after all :)

-Matej

>
> This is not a big deal though, either way is fine by me.
>
> Best wishes,
> Timo
>
> --
> Timo Rantalaiho
> Reaktor Innovations Oy    <URL: http://www.ri.fi/ >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

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