You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Brill Pappin <br...@pappin.ca> on 2009/03/12 15:52:00 UTC
can we get this patch applied to the current snapshot?
https://issues.apache.org/jira/browse/WICKET-2137
- Brill
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by Jeremy Thomerson <je...@wickettraining.com>.
after removing the "? extends" it will...
// THIS WORKS:
List<Integer> list1 = new ArrayList<Integer>();
list1.add(new Integer(4));
list1.add(4);
// THIS DOES NOT WORK:
List<? extends Integer> list2 = new ArrayList<? extends Integer>();
list2.add(new Integer(4));
list2.add(4);
--
Jeremy Thomerson
http://www.wickettraining.com
On Fri, Mar 13, 2009 at 12:50 AM, Igor Vaynberg <ig...@gmail.com>wrote:
> palette needs to be able to do:
>
> getmodelobject().clear();
> getmodelobject().add(item);
>
> where getmodelobject should return a collection.
>
> will that still work with this refactor? i dont see why components
> that do this need to cast anything to make it work.
>
> -igor
>
> On Thu, Mar 12, 2009 at 10:43 PM, James Carman
> <jc...@carmanconsulting.com> wrote:
> > To be clear, the only potential for breakage is where user code tries
> > to modify the returned "model object" (of type List<? extends T>)
> > without casting it. However, that's a rare usecase (in my opinion)
> > and again it's easily overcome by a simple cast.
> >
> > On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg <ig...@gmail.com>
> wrote:
> >> before applying an api-breaking patch to an rc release we should have
> >> a vote on the dev list.
> >>
> >> -igor
> >>
> >> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
> >> <je...@wickettraining.com> wrote:
> >>> Unless I'm seeing double - this patch has two problems:
> >>>
> >>> 1 - It is the opposite of what was voted on. The vote was to make
> >>> IModel<List<? extends E>> into IModel<List<E>>. Your patch makes it
> >>> IModel<? extends List<? extends E>>.
> >>>
> >>> 2 - The patch causes compile errors that were not fixed.
> >>>
> >>> I have unassigned myself from the task until those issues are addressed
> or I
> >>> have time to create my own patch. The best solution would be for
> someone to
> >>> submit a proper patch that fixes the two problems above or explain to
> me
> >>> what I missed.
> >>>
> >>> Thanks!
> >>>
> >>> --
> >>> Jeremy Thomerson
> >>> http://www.wickettraining.com
> >>>
> >>>
> >>>
> >>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson <
> jeremy@wickettraining.com
> >>>> wrote:
> >>>
> >>>> I'm reviewing it now. Assuming that it looks fine, and is line with
> what
> >>>> was proposed by the vote thread earlier, I will apply. The vote
> passed, so
> >>>> I don't see a reason not to. I'm not sure how many were binding /
> >>>> non-binding, but there were eight for, two against.
> >>>>
> >>>> --
> >>>> Jeremy Thomerson
> >>>> http://www.wickettraining.com
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin <br...@pappin.ca>
> wrote:
> >>>>
> >>>>> https://issues.apache.org/jira/browse/WICKET-2137
> >>>>>
> >>>>> - Brill
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: can we get this patch applied to the current snapshot?
Posted by James Carman <jc...@carmanconsulting.com>.
I didn't change any of the "guts" of Palette (I did change Recorder, a
bit) in my patch. So, I guess the answer is "yes", it will work. All
of the unit tests pass.
On Fri, Mar 13, 2009 at 1:50 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> palette needs to be able to do:
>
> getmodelobject().clear();
> getmodelobject().add(item);
>
> where getmodelobject should return a collection.
>
> will that still work with this refactor? i dont see why components
> that do this need to cast anything to make it work.
>
> -igor
>
> On Thu, Mar 12, 2009 at 10:43 PM, James Carman
> <jc...@carmanconsulting.com> wrote:
>> To be clear, the only potential for breakage is where user code tries
>> to modify the returned "model object" (of type List<? extends T>)
>> without casting it. However, that's a rare usecase (in my opinion)
>> and again it's easily overcome by a simple cast.
>>
>> On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>> before applying an api-breaking patch to an rc release we should have
>>> a vote on the dev list.
>>>
>>> -igor
>>>
>>> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
>>> <je...@wickettraining.com> wrote:
>>>> Unless I'm seeing double - this patch has two problems:
>>>>
>>>> 1 - It is the opposite of what was voted on. The vote was to make
>>>> IModel<List<? extends E>> into IModel<List<E>>. Your patch makes it
>>>> IModel<? extends List<? extends E>>.
>>>>
>>>> 2 - The patch causes compile errors that were not fixed.
>>>>
>>>> I have unassigned myself from the task until those issues are addressed or I
>>>> have time to create my own patch. The best solution would be for someone to
>>>> submit a proper patch that fixes the two problems above or explain to me
>>>> what I missed.
>>>>
>>>> Thanks!
>>>>
>>>> --
>>>> Jeremy Thomerson
>>>> http://www.wickettraining.com
>>>>
>>>>
>>>>
>>>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson <jeremy@wickettraining.com
>>>>> wrote:
>>>>
>>>>> I'm reviewing it now. Assuming that it looks fine, and is line with what
>>>>> was proposed by the vote thread earlier, I will apply. The vote passed, so
>>>>> I don't see a reason not to. I'm not sure how many were binding /
>>>>> non-binding, but there were eight for, two against.
>>>>>
>>>>> --
>>>>> Jeremy Thomerson
>>>>> http://www.wickettraining.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>>>
>>>>>> https://issues.apache.org/jira/browse/WICKET-2137
>>>>>>
>>>>>> - Brill
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by Igor Vaynberg <ig...@gmail.com>.
palette needs to be able to do:
getmodelobject().clear();
getmodelobject().add(item);
where getmodelobject should return a collection.
will that still work with this refactor? i dont see why components
that do this need to cast anything to make it work.
-igor
On Thu, Mar 12, 2009 at 10:43 PM, James Carman
<jc...@carmanconsulting.com> wrote:
> To be clear, the only potential for breakage is where user code tries
> to modify the returned "model object" (of type List<? extends T>)
> without casting it. However, that's a rare usecase (in my opinion)
> and again it's easily overcome by a simple cast.
>
> On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>> before applying an api-breaking patch to an rc release we should have
>> a vote on the dev list.
>>
>> -igor
>>
>> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
>> <je...@wickettraining.com> wrote:
>>> Unless I'm seeing double - this patch has two problems:
>>>
>>> 1 - It is the opposite of what was voted on. The vote was to make
>>> IModel<List<? extends E>> into IModel<List<E>>. Your patch makes it
>>> IModel<? extends List<? extends E>>.
>>>
>>> 2 - The patch causes compile errors that were not fixed.
>>>
>>> I have unassigned myself from the task until those issues are addressed or I
>>> have time to create my own patch. The best solution would be for someone to
>>> submit a proper patch that fixes the two problems above or explain to me
>>> what I missed.
>>>
>>> Thanks!
>>>
>>> --
>>> Jeremy Thomerson
>>> http://www.wickettraining.com
>>>
>>>
>>>
>>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson <jeremy@wickettraining.com
>>>> wrote:
>>>
>>>> I'm reviewing it now. Assuming that it looks fine, and is line with what
>>>> was proposed by the vote thread earlier, I will apply. The vote passed, so
>>>> I don't see a reason not to. I'm not sure how many were binding /
>>>> non-binding, but there were eight for, two against.
>>>>
>>>> --
>>>> Jeremy Thomerson
>>>> http://www.wickettraining.com
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>>
>>>>> https://issues.apache.org/jira/browse/WICKET-2137
>>>>>
>>>>> - Brill
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by Igor Vaynberg <ig...@gmail.com>.
yes, you are right, the red squiggle i got in the ide was actually :
error: this variable might not have been initialized :|
-igor
On Fri, Mar 13, 2009 at 1:39 PM, James Carman
<jc...@carmanconsulting.com> wrote:
> As I said before, my patch for WICKET-2165 doesn't change any test or
> example code at all and everything builds just fine. There are plenty
> of examples in the test and example code where you pass in a
> IModel<List<T>> to the constructor and it all is still working. Take
> for example the FileListView class in the MultiUploadPage example from
> wicket-examples. It's passing an IModel<List<File>> to its
> superclass' (ListView) constructor. No issues.
>
> On Fri, Mar 13, 2009 at 4:33 PM, James Carman
> <jc...@carmanconsulting.com> wrote:
>> I did! I added a simple class to my wicket development project that
>> has all of my changes applied for WICKET-2165. In IDEA when I hit
>> Ctrl-B (go to declaration) it takes me to a constructor with this
>> signature:
>>
>> public ListView(final String id, final IModel<? extends List<? extends
>> T>> model)
>>
>> If you don't believe me, just try this to verify:
>>
>> public class ListManager<T> extends Panel
>> {
>> public ListManager(String id, IModel<List<T>> entries)
>> {
>> super(id);
>> someMethod(entries);
>> }
>>
>> private void someMethod(IModel<? extends List<? extends T>> model)
>> {
>> // Do nothing!
>> }
>> }
>>
>> This compiles just fine.
>>
>> On Fri, Mar 13, 2009 at 4:25 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>> now change listview to take imodel<? extends List<? extends T>>
>>>
>>> -igor
>>>
>>> On Fri, Mar 13, 2009 at 1:00 PM, James Carman
>>> <jc...@carmanconsulting.com> wrote:
>>>> Ok, what part are you talking about that doesn't compile? In my IDE
>>>> right now, I have:
>>>>
>>>> public class ListManager<T> extends Panel
>>>> {
>>>> public ListManager(String id, IModel<List<T>> entries)
>>>> {
>>>> super(id);
>>>> add(new ListView<T>("list", entries)
>>>> {
>>>> protected void populateItem(ListItem<T> item)
>>>> {
>>>>
>>>> }
>>>> });
>>>> }
>>>> }
>>>>
>>>> This all checks out fine. I didn't use the form part because Panel's
>>>> getDefaultModelObject() method returns Object, and you can't call
>>>> add() on that, so I assumed that was just for illustrative purposes.
>>>>
>>>>
>>>> On Fri, Mar 13, 2009 at 2:57 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>>> yes, sorry
>>>>>
>>>>> class listmanager<t> extends panel {
>>>>>
>>>>> public listmanager(string id, imodel<list<t>> entries) {
>>>>> add(new form("form") { onsubmit() {
>>>>> listmanager.this.getmodelobject().add(someentry);}}
>>>>> add(new listview<t>("list", entries){});
>>>>>
>>>>>
>>>>> -igor
>>>>>
>>>>> On Fri, Mar 13, 2009 at 11:51 AM, James Carman
>>>>> <ja...@carmanconsulting.com> wrote:
>>>>>> If T is the element type, then you can't use an IModel<T> for the choices.
>>>>>> You can't do that with the current API. Did you mean to pass in an
>>>>>> IModel<List<T>> to the constructor?
>>>>>>
>>>>>> On Mar 13, 2009 2:45 PM, "Igor Vaynberg" <ig...@gmail.com> wrote:
>>>>>>
>>>>>> t is the type of a list element, see below
>>>>>>
>>>>>> class listmanager<t> extends panel {
>>>>>>
>>>>>> public listmanager(string id, imodel<t> entries) {
>>>>>> add(new form("form") { onsubmit() {
>>>>>> listmanager.this.getmodelobject().add(someentry);}}
>>>>>> add(new listview<t>("list", entries){});
>>>>>>
>>>>>> ^ wont compile because you cant assign imodel<t> to imodel<? extends list<?
>>>>>> extends t>> so we ha...
>>>>>>
>>>>>> On Fri, Mar 13, 2009 at 8:59 AM, James Carman <jc...@carmanconsulting.com>
>>>>>> wrote: > T has to be a ...
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by James Carman <jc...@carmanconsulting.com>.
As I said before, my patch for WICKET-2165 doesn't change any test or
example code at all and everything builds just fine. There are plenty
of examples in the test and example code where you pass in a
IModel<List<T>> to the constructor and it all is still working. Take
for example the FileListView class in the MultiUploadPage example from
wicket-examples. It's passing an IModel<List<File>> to its
superclass' (ListView) constructor. No issues.
On Fri, Mar 13, 2009 at 4:33 PM, James Carman
<jc...@carmanconsulting.com> wrote:
> I did! I added a simple class to my wicket development project that
> has all of my changes applied for WICKET-2165. In IDEA when I hit
> Ctrl-B (go to declaration) it takes me to a constructor with this
> signature:
>
> public ListView(final String id, final IModel<? extends List<? extends
> T>> model)
>
> If you don't believe me, just try this to verify:
>
> public class ListManager<T> extends Panel
> {
> public ListManager(String id, IModel<List<T>> entries)
> {
> super(id);
> someMethod(entries);
> }
>
> private void someMethod(IModel<? extends List<? extends T>> model)
> {
> // Do nothing!
> }
> }
>
> This compiles just fine.
>
> On Fri, Mar 13, 2009 at 4:25 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>> now change listview to take imodel<? extends List<? extends T>>
>>
>> -igor
>>
>> On Fri, Mar 13, 2009 at 1:00 PM, James Carman
>> <jc...@carmanconsulting.com> wrote:
>>> Ok, what part are you talking about that doesn't compile? In my IDE
>>> right now, I have:
>>>
>>> public class ListManager<T> extends Panel
>>> {
>>> public ListManager(String id, IModel<List<T>> entries)
>>> {
>>> super(id);
>>> add(new ListView<T>("list", entries)
>>> {
>>> protected void populateItem(ListItem<T> item)
>>> {
>>>
>>> }
>>> });
>>> }
>>> }
>>>
>>> This all checks out fine. I didn't use the form part because Panel's
>>> getDefaultModelObject() method returns Object, and you can't call
>>> add() on that, so I assumed that was just for illustrative purposes.
>>>
>>>
>>> On Fri, Mar 13, 2009 at 2:57 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>> yes, sorry
>>>>
>>>> class listmanager<t> extends panel {
>>>>
>>>> public listmanager(string id, imodel<list<t>> entries) {
>>>> add(new form("form") { onsubmit() {
>>>> listmanager.this.getmodelobject().add(someentry);}}
>>>> add(new listview<t>("list", entries){});
>>>>
>>>>
>>>> -igor
>>>>
>>>> On Fri, Mar 13, 2009 at 11:51 AM, James Carman
>>>> <ja...@carmanconsulting.com> wrote:
>>>>> If T is the element type, then you can't use an IModel<T> for the choices.
>>>>> You can't do that with the current API. Did you mean to pass in an
>>>>> IModel<List<T>> to the constructor?
>>>>>
>>>>> On Mar 13, 2009 2:45 PM, "Igor Vaynberg" <ig...@gmail.com> wrote:
>>>>>
>>>>> t is the type of a list element, see below
>>>>>
>>>>> class listmanager<t> extends panel {
>>>>>
>>>>> public listmanager(string id, imodel<t> entries) {
>>>>> add(new form("form") { onsubmit() {
>>>>> listmanager.this.getmodelobject().add(someentry);}}
>>>>> add(new listview<t>("list", entries){});
>>>>>
>>>>> ^ wont compile because you cant assign imodel<t> to imodel<? extends list<?
>>>>> extends t>> so we ha...
>>>>>
>>>>> On Fri, Mar 13, 2009 at 8:59 AM, James Carman <jc...@carmanconsulting.com>
>>>>> wrote: > T has to be a ...
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by James Carman <jc...@carmanconsulting.com>.
I did! I added a simple class to my wicket development project that
has all of my changes applied for WICKET-2165. In IDEA when I hit
Ctrl-B (go to declaration) it takes me to a constructor with this
signature:
public ListView(final String id, final IModel<? extends List<? extends
T>> model)
If you don't believe me, just try this to verify:
public class ListManager<T> extends Panel
{
public ListManager(String id, IModel<List<T>> entries)
{
super(id);
someMethod(entries);
}
private void someMethod(IModel<? extends List<? extends T>> model)
{
// Do nothing!
}
}
This compiles just fine.
On Fri, Mar 13, 2009 at 4:25 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> now change listview to take imodel<? extends List<? extends T>>
>
> -igor
>
> On Fri, Mar 13, 2009 at 1:00 PM, James Carman
> <jc...@carmanconsulting.com> wrote:
>> Ok, what part are you talking about that doesn't compile? In my IDE
>> right now, I have:
>>
>> public class ListManager<T> extends Panel
>> {
>> public ListManager(String id, IModel<List<T>> entries)
>> {
>> super(id);
>> add(new ListView<T>("list", entries)
>> {
>> protected void populateItem(ListItem<T> item)
>> {
>>
>> }
>> });
>> }
>> }
>>
>> This all checks out fine. I didn't use the form part because Panel's
>> getDefaultModelObject() method returns Object, and you can't call
>> add() on that, so I assumed that was just for illustrative purposes.
>>
>>
>> On Fri, Mar 13, 2009 at 2:57 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>> yes, sorry
>>>
>>> class listmanager<t> extends panel {
>>>
>>> public listmanager(string id, imodel<list<t>> entries) {
>>> add(new form("form") { onsubmit() {
>>> listmanager.this.getmodelobject().add(someentry);}}
>>> add(new listview<t>("list", entries){});
>>>
>>>
>>> -igor
>>>
>>> On Fri, Mar 13, 2009 at 11:51 AM, James Carman
>>> <ja...@carmanconsulting.com> wrote:
>>>> If T is the element type, then you can't use an IModel<T> for the choices.
>>>> You can't do that with the current API. Did you mean to pass in an
>>>> IModel<List<T>> to the constructor?
>>>>
>>>> On Mar 13, 2009 2:45 PM, "Igor Vaynberg" <ig...@gmail.com> wrote:
>>>>
>>>> t is the type of a list element, see below
>>>>
>>>> class listmanager<t> extends panel {
>>>>
>>>> public listmanager(string id, imodel<t> entries) {
>>>> add(new form("form") { onsubmit() {
>>>> listmanager.this.getmodelobject().add(someentry);}}
>>>> add(new listview<t>("list", entries){});
>>>>
>>>> ^ wont compile because you cant assign imodel<t> to imodel<? extends list<?
>>>> extends t>> so we ha...
>>>>
>>>> On Fri, Mar 13, 2009 at 8:59 AM, James Carman <jc...@carmanconsulting.com>
>>>> wrote: > T has to be a ...
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by Igor Vaynberg <ig...@gmail.com>.
now change listview to take imodel<? extends List<? extends T>>
-igor
On Fri, Mar 13, 2009 at 1:00 PM, James Carman
<jc...@carmanconsulting.com> wrote:
> Ok, what part are you talking about that doesn't compile? In my IDE
> right now, I have:
>
> public class ListManager<T> extends Panel
> {
> public ListManager(String id, IModel<List<T>> entries)
> {
> super(id);
> add(new ListView<T>("list", entries)
> {
> protected void populateItem(ListItem<T> item)
> {
>
> }
> });
> }
> }
>
> This all checks out fine. I didn't use the form part because Panel's
> getDefaultModelObject() method returns Object, and you can't call
> add() on that, so I assumed that was just for illustrative purposes.
>
>
> On Fri, Mar 13, 2009 at 2:57 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>> yes, sorry
>>
>> class listmanager<t> extends panel {
>>
>> public listmanager(string id, imodel<list<t>> entries) {
>> add(new form("form") { onsubmit() {
>> listmanager.this.getmodelobject().add(someentry);}}
>> add(new listview<t>("list", entries){});
>>
>>
>> -igor
>>
>> On Fri, Mar 13, 2009 at 11:51 AM, James Carman
>> <ja...@carmanconsulting.com> wrote:
>>> If T is the element type, then you can't use an IModel<T> for the choices.
>>> You can't do that with the current API. Did you mean to pass in an
>>> IModel<List<T>> to the constructor?
>>>
>>> On Mar 13, 2009 2:45 PM, "Igor Vaynberg" <ig...@gmail.com> wrote:
>>>
>>> t is the type of a list element, see below
>>>
>>> class listmanager<t> extends panel {
>>>
>>> public listmanager(string id, imodel<t> entries) {
>>> add(new form("form") { onsubmit() {
>>> listmanager.this.getmodelobject().add(someentry);}}
>>> add(new listview<t>("list", entries){});
>>>
>>> ^ wont compile because you cant assign imodel<t> to imodel<? extends list<?
>>> extends t>> so we ha...
>>>
>>> On Fri, Mar 13, 2009 at 8:59 AM, James Carman <jc...@carmanconsulting.com>
>>> wrote: > T has to be a ...
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by James Carman <jc...@carmanconsulting.com>.
Ok, what part are you talking about that doesn't compile? In my IDE
right now, I have:
public class ListManager<T> extends Panel
{
public ListManager(String id, IModel<List<T>> entries)
{
super(id);
add(new ListView<T>("list", entries)
{
protected void populateItem(ListItem<T> item)
{
}
});
}
}
This all checks out fine. I didn't use the form part because Panel's
getDefaultModelObject() method returns Object, and you can't call
add() on that, so I assumed that was just for illustrative purposes.
On Fri, Mar 13, 2009 at 2:57 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> yes, sorry
>
> class listmanager<t> extends panel {
>
> public listmanager(string id, imodel<list<t>> entries) {
> add(new form("form") { onsubmit() {
> listmanager.this.getmodelobject().add(someentry);}}
> add(new listview<t>("list", entries){});
>
>
> -igor
>
> On Fri, Mar 13, 2009 at 11:51 AM, James Carman
> <ja...@carmanconsulting.com> wrote:
>> If T is the element type, then you can't use an IModel<T> for the choices.
>> You can't do that with the current API. Did you mean to pass in an
>> IModel<List<T>> to the constructor?
>>
>> On Mar 13, 2009 2:45 PM, "Igor Vaynberg" <ig...@gmail.com> wrote:
>>
>> t is the type of a list element, see below
>>
>> class listmanager<t> extends panel {
>>
>> public listmanager(string id, imodel<t> entries) {
>> add(new form("form") { onsubmit() {
>> listmanager.this.getmodelobject().add(someentry);}}
>> add(new listview<t>("list", entries){});
>>
>> ^ wont compile because you cant assign imodel<t> to imodel<? extends list<?
>> extends t>> so we ha...
>>
>> On Fri, Mar 13, 2009 at 8:59 AM, James Carman <jc...@carmanconsulting.com>
>> wrote: > T has to be a ...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by Igor Vaynberg <ig...@gmail.com>.
yes, sorry
class listmanager<t> extends panel {
public listmanager(string id, imodel<list<t>> entries) {
add(new form("form") { onsubmit() {
listmanager.this.getmodelobject().add(someentry);}}
add(new listview<t>("list", entries){});
-igor
On Fri, Mar 13, 2009 at 11:51 AM, James Carman
<ja...@carmanconsulting.com> wrote:
> If T is the element type, then you can't use an IModel<T> for the choices.
> You can't do that with the current API. Did you mean to pass in an
> IModel<List<T>> to the constructor?
>
> On Mar 13, 2009 2:45 PM, "Igor Vaynberg" <ig...@gmail.com> wrote:
>
> t is the type of a list element, see below
>
> class listmanager<t> extends panel {
>
> public listmanager(string id, imodel<t> entries) {
> add(new form("form") { onsubmit() {
> listmanager.this.getmodelobject().add(someentry);}}
> add(new listview<t>("list", entries){});
>
> ^ wont compile because you cant assign imodel<t> to imodel<? extends list<?
> extends t>> so we ha...
>
> On Fri, Mar 13, 2009 at 8:59 AM, James Carman <jc...@carmanconsulting.com>
> wrote: > T has to be a ...
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by James Carman <ja...@carmanconsulting.com>.
If T is the element type, then you can't use an IModel<T> for the choices.
You can't do that with the current API. Did you mean to pass in an
IModel<List<T>> to the constructor?
On Mar 13, 2009 2:45 PM, "Igor Vaynberg" <ig...@gmail.com> wrote:
t is the type of a list element, see below
class listmanager<t> extends panel {
public listmanager(string id, imodel<t> entries) {
add(new form("form") { onsubmit() {
listmanager.this.getmodelobject().add(someentry);}}
add(new listview<t>("list", entries){});
^ wont compile because you cant assign imodel<t> to imodel<? extends list<?
extends t>> so we ha...
On Fri, Mar 13, 2009 at 8:59 AM, James Carman <jc...@carmanconsulting.com>
wrote: > T has to be a ...
Re: can we get this patch applied to the current snapshot?
Posted by Igor Vaynberg <ig...@gmail.com>.
t is the type of a list element, see below
class listmanager<t> extends panel {
public listmanager(string id, imodel<t> entries) {
add(new form("form") { onsubmit() {
listmanager.this.getmodelobject().add(someentry);}}
add(new listview<t>("list", entries){});
^ wont compile because you cant assign imodel<t> to imodel<?
extends list<? extends t>> so we have to cast???
-igor
On Fri, Mar 13, 2009 at 8:59 AM, James Carman
<jc...@carmanconsulting.com> wrote:
> T has to be a list of some sort in this case and you would want to
> convey that in your API. Are you wanting T to be the element type
> here or the list type itself. I'm really having a hard time following
> what you're trying to do here. What type parameter are you passing
> into your listview?
>
> On Fri, Mar 13, 2009 at 11:53 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>> the problem remains.
>>
>> lets say we change listview to take imodel<? extends List<? extends T>>
>>
>> i want to do something like this:
>>
>> class listmanger<t> extends panel {
>> public listmanager(string id, imodel<t> entries) {
>> addformtoaddtems();
>> add(new listview("list", entities));
>> ^ wont compile because you cant assign imodel<t> to imodel<?
>> extends list<? extends t>> so we have to cast???
>>
>> -igor
>>
>> On Fri, Mar 13, 2009 at 8:02 AM, James Carman
>> <jc...@carmanconsulting.com> wrote:
>>> Yes, but that's fine. The idea is that I want to collect a
>>> List<Apple>, but I want to choose from a List<GrannySmithApple>. That
>>> should be allowed.
>>>
>>>
>>> On Fri, Mar 13, 2009 at 10:42 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>> so then again you are back to something taking imodel<list<t>> and a
>>>> widened version in the same constructor.
>>>>
>>>> -igor
>>>>
>>>> On Fri, Mar 13, 2009 at 3:54 AM, James Carman
>>>> <jc...@carmanconsulting.com> wrote:
>>>>> Again, ListMultipleChoice is okay in this instance. You don't want to
>>>>> "widen" the model. You want to widen what can go in it (the choices),
>>>>> which I have.
>>>>>
>>>>> On Fri, Mar 13, 2009 at 3:40 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>>>> taking ListMultipleChoice as another example, your patch leaves it us
>>>>>>
>>>>>> public class ListMultipleChoice<T> extends AbstractChoice<Collection<T>, T>
>>>>>>
>>>>>> when in fact it should be properly declared as
>>>>>>
>>>>>> public class ListMultipleChoice<T> extends AbstractChoice<Collection<?
>>>>>> extends T>, T>
>>>>>>
>>>>>> so that getModelObject() properly returns Collection<? extends T>
>>>>>> instead of the unsafe variant Collection<T>
>>>>>>
>>>>>> which, once again, will break updatemodel()
>>>>>>
>>>>>> in your experience you havent ran into a situation where a component
>>>>>> updates its collection model object. my experience is quiet the
>>>>>> opposite. just trying to make sure we do not paint ourselves into a
>>>>>> corner.
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>> On Fri, Mar 13, 2009 at 12:31 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>>>>> your patch works because it does not properly refactor
>>>>>>> Palette#getModelCollection(). you left it us:
>>>>>>>
>>>>>>> public Collection<T> getModelCollection()
>>>>>>> {
>>>>>>> return (Collection<T>)getDefaultModelObject();
>>>>>>> }
>>>>>>>
>>>>>>> which is incorrect, it should in fact now return Collection<? extends
>>>>>>> T>, which will break Palette#updateModel()
>>>>>>>
>>>>>>> -igor
>>>>>>>
>>>>>>> On Thu, Mar 12, 2009 at 11:32 PM, James Carman
>>>>>>> <jc...@carmanconsulting.com> wrote:
>>>>>>>> FYI,
>>>>>>>>
>>>>>>>> I have created a new JIRA issue for my proposed API changes:
>>>>>>>>
>>>>>>>> https://issues.apache.org/jira/browse/WICKET-2165
>>>>>>>>
>>>>>>>> I've attached a patch. I've "fixed" all of the places I could find
>>>>>>>> thus far. If I find anymore, I'll upload a new patch.
>>>>>>>>
>>>>>>>> James
>>>>>>>>
>>>>>>>> On Fri, Mar 13, 2009 at 1:59 AM, James Carman
>>>>>>>> <jc...@carmanconsulting.com> wrote:
>>>>>>>>> "Feeding" the list to your component isn't the issue (the constructor
>>>>>>>>> will take what you throw at it). It's using the
>>>>>>>>> getDefaultModelObject() method and trying to modify that list once
>>>>>>>>> you've passed it in that will cause you to have to cast.
>>>>>>>>>
>>>>>>>>> On Fri, Mar 13, 2009 at 1:54 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>>>>>>>> I'm really not sure of all the use-cases... all I know is that I spent some
>>>>>>>>>> time trying to get the darn thing to compile using a fairly basic wicket
>>>>>>>>>> pattern.
>>>>>>>>>>
>>>>>>>>>> If such a simple thing as feeding a list of items to a component that draws
>>>>>>>>>> a list using them is going to give me that much trouble (knowing a
>>>>>>>>>> workaround or not), then there is something definitely broken.
>>>>>>>>>>
>>>>>>>>>> - Brill
>>>>>>>>>>
>>>>>>>>>> On 13-Mar-09, at 1:43 AM, James Carman wrote:
>>>>>>>>>>
>>>>>>>>>>> To be clear, the only potential for breakage is where user code tries
>>>>>>>>>>> to modify the returned "model object" (of type List<? extends T>)
>>>>>>>>>>> without casting it. However, that's a rare usecase (in my opinion)
>>>>>>>>>>> and again it's easily overcome by a simple cast.
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg <ig...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> before applying an api-breaking patch to an rc release we should have
>>>>>>>>>>>> a vote on the dev list.
>>>>>>>>>>>>
>>>>>>>>>>>> -igor
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
>>>>>>>>>>>> <je...@wickettraining.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Unless I'm seeing double - this patch has two problems:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1 - It is the opposite of what was voted on. The vote was to make
>>>>>>>>>>>>> IModel<List<? extends E>> into IModel<List<E>>. Your patch makes it
>>>>>>>>>>>>> IModel<? extends List<? extends E>>.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2 - The patch causes compile errors that were not fixed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have unassigned myself from the task until those issues are addressed
>>>>>>>>>>>>> or I
>>>>>>>>>>>>> have time to create my own patch. The best solution would be for
>>>>>>>>>>>>> someone to
>>>>>>>>>>>>> submit a proper patch that fixes the two problems above or explain to me
>>>>>>>>>>>>> what I missed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Jeremy Thomerson
>>>>>>>>>>>>> http://www.wickettraining.com
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson
>>>>>>>>>>>>> <jeremy@wickettraining.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm reviewing it now. Assuming that it looks fine, and is line with
>>>>>>>>>>>>>> what
>>>>>>>>>>>>>> was proposed by the vote thread earlier, I will apply. The vote
>>>>>>>>>>>>>> passed, so
>>>>>>>>>>>>>> I don't see a reason not to. I'm not sure how many were binding /
>>>>>>>>>>>>>> non-binding, but there were eight for, two against.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Jeremy Thomerson
>>>>>>>>>>>>>> http://www.wickettraining.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/WICKET-2137
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Brill
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by James Carman <jc...@carmanconsulting.com>.
T has to be a list of some sort in this case and you would want to
convey that in your API. Are you wanting T to be the element type
here or the list type itself. I'm really having a hard time following
what you're trying to do here. What type parameter are you passing
into your listview?
On Fri, Mar 13, 2009 at 11:53 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> the problem remains.
>
> lets say we change listview to take imodel<? extends List<? extends T>>
>
> i want to do something like this:
>
> class listmanger<t> extends panel {
> public listmanager(string id, imodel<t> entries) {
> addformtoaddtems();
> add(new listview("list", entities));
> ^ wont compile because you cant assign imodel<t> to imodel<?
> extends list<? extends t>> so we have to cast???
>
> -igor
>
> On Fri, Mar 13, 2009 at 8:02 AM, James Carman
> <jc...@carmanconsulting.com> wrote:
>> Yes, but that's fine. The idea is that I want to collect a
>> List<Apple>, but I want to choose from a List<GrannySmithApple>. That
>> should be allowed.
>>
>>
>> On Fri, Mar 13, 2009 at 10:42 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>>> so then again you are back to something taking imodel<list<t>> and a
>>> widened version in the same constructor.
>>>
>>> -igor
>>>
>>> On Fri, Mar 13, 2009 at 3:54 AM, James Carman
>>> <jc...@carmanconsulting.com> wrote:
>>>> Again, ListMultipleChoice is okay in this instance. You don't want to
>>>> "widen" the model. You want to widen what can go in it (the choices),
>>>> which I have.
>>>>
>>>> On Fri, Mar 13, 2009 at 3:40 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>>> taking ListMultipleChoice as another example, your patch leaves it us
>>>>>
>>>>> public class ListMultipleChoice<T> extends AbstractChoice<Collection<T>, T>
>>>>>
>>>>> when in fact it should be properly declared as
>>>>>
>>>>> public class ListMultipleChoice<T> extends AbstractChoice<Collection<?
>>>>> extends T>, T>
>>>>>
>>>>> so that getModelObject() properly returns Collection<? extends T>
>>>>> instead of the unsafe variant Collection<T>
>>>>>
>>>>> which, once again, will break updatemodel()
>>>>>
>>>>> in your experience you havent ran into a situation where a component
>>>>> updates its collection model object. my experience is quiet the
>>>>> opposite. just trying to make sure we do not paint ourselves into a
>>>>> corner.
>>>>>
>>>>> -igor
>>>>>
>>>>> On Fri, Mar 13, 2009 at 12:31 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>>>> your patch works because it does not properly refactor
>>>>>> Palette#getModelCollection(). you left it us:
>>>>>>
>>>>>> public Collection<T> getModelCollection()
>>>>>> {
>>>>>> return (Collection<T>)getDefaultModelObject();
>>>>>> }
>>>>>>
>>>>>> which is incorrect, it should in fact now return Collection<? extends
>>>>>> T>, which will break Palette#updateModel()
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>> On Thu, Mar 12, 2009 at 11:32 PM, James Carman
>>>>>> <jc...@carmanconsulting.com> wrote:
>>>>>>> FYI,
>>>>>>>
>>>>>>> I have created a new JIRA issue for my proposed API changes:
>>>>>>>
>>>>>>> https://issues.apache.org/jira/browse/WICKET-2165
>>>>>>>
>>>>>>> I've attached a patch. I've "fixed" all of the places I could find
>>>>>>> thus far. If I find anymore, I'll upload a new patch.
>>>>>>>
>>>>>>> James
>>>>>>>
>>>>>>> On Fri, Mar 13, 2009 at 1:59 AM, James Carman
>>>>>>> <jc...@carmanconsulting.com> wrote:
>>>>>>>> "Feeding" the list to your component isn't the issue (the constructor
>>>>>>>> will take what you throw at it). It's using the
>>>>>>>> getDefaultModelObject() method and trying to modify that list once
>>>>>>>> you've passed it in that will cause you to have to cast.
>>>>>>>>
>>>>>>>> On Fri, Mar 13, 2009 at 1:54 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>>>>>>> I'm really not sure of all the use-cases... all I know is that I spent some
>>>>>>>>> time trying to get the darn thing to compile using a fairly basic wicket
>>>>>>>>> pattern.
>>>>>>>>>
>>>>>>>>> If such a simple thing as feeding a list of items to a component that draws
>>>>>>>>> a list using them is going to give me that much trouble (knowing a
>>>>>>>>> workaround or not), then there is something definitely broken.
>>>>>>>>>
>>>>>>>>> - Brill
>>>>>>>>>
>>>>>>>>> On 13-Mar-09, at 1:43 AM, James Carman wrote:
>>>>>>>>>
>>>>>>>>>> To be clear, the only potential for breakage is where user code tries
>>>>>>>>>> to modify the returned "model object" (of type List<? extends T>)
>>>>>>>>>> without casting it. However, that's a rare usecase (in my opinion)
>>>>>>>>>> and again it's easily overcome by a simple cast.
>>>>>>>>>>
>>>>>>>>>> On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg <ig...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> before applying an api-breaking patch to an rc release we should have
>>>>>>>>>>> a vote on the dev list.
>>>>>>>>>>>
>>>>>>>>>>> -igor
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
>>>>>>>>>>> <je...@wickettraining.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Unless I'm seeing double - this patch has two problems:
>>>>>>>>>>>>
>>>>>>>>>>>> 1 - It is the opposite of what was voted on. The vote was to make
>>>>>>>>>>>> IModel<List<? extends E>> into IModel<List<E>>. Your patch makes it
>>>>>>>>>>>> IModel<? extends List<? extends E>>.
>>>>>>>>>>>>
>>>>>>>>>>>> 2 - The patch causes compile errors that were not fixed.
>>>>>>>>>>>>
>>>>>>>>>>>> I have unassigned myself from the task until those issues are addressed
>>>>>>>>>>>> or I
>>>>>>>>>>>> have time to create my own patch. The best solution would be for
>>>>>>>>>>>> someone to
>>>>>>>>>>>> submit a proper patch that fixes the two problems above or explain to me
>>>>>>>>>>>> what I missed.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Jeremy Thomerson
>>>>>>>>>>>> http://www.wickettraining.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson
>>>>>>>>>>>> <jeremy@wickettraining.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I'm reviewing it now. Assuming that it looks fine, and is line with
>>>>>>>>>>>>> what
>>>>>>>>>>>>> was proposed by the vote thread earlier, I will apply. The vote
>>>>>>>>>>>>> passed, so
>>>>>>>>>>>>> I don't see a reason not to. I'm not sure how many were binding /
>>>>>>>>>>>>> non-binding, but there were eight for, two against.
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Jeremy Thomerson
>>>>>>>>>>>>> http://www.wickettraining.com
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/WICKET-2137
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Brill
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by Igor Vaynberg <ig...@gmail.com>.
the problem remains.
lets say we change listview to take imodel<? extends List<? extends T>>
i want to do something like this:
class listmanger<t> extends panel {
public listmanager(string id, imodel<t> entries) {
addformtoaddtems();
add(new listview("list", entities));
^ wont compile because you cant assign imodel<t> to imodel<?
extends list<? extends t>> so we have to cast???
-igor
On Fri, Mar 13, 2009 at 8:02 AM, James Carman
<jc...@carmanconsulting.com> wrote:
> Yes, but that's fine. The idea is that I want to collect a
> List<Apple>, but I want to choose from a List<GrannySmithApple>. That
> should be allowed.
>
>
> On Fri, Mar 13, 2009 at 10:42 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>> so then again you are back to something taking imodel<list<t>> and a
>> widened version in the same constructor.
>>
>> -igor
>>
>> On Fri, Mar 13, 2009 at 3:54 AM, James Carman
>> <jc...@carmanconsulting.com> wrote:
>>> Again, ListMultipleChoice is okay in this instance. You don't want to
>>> "widen" the model. You want to widen what can go in it (the choices),
>>> which I have.
>>>
>>> On Fri, Mar 13, 2009 at 3:40 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>> taking ListMultipleChoice as another example, your patch leaves it us
>>>>
>>>> public class ListMultipleChoice<T> extends AbstractChoice<Collection<T>, T>
>>>>
>>>> when in fact it should be properly declared as
>>>>
>>>> public class ListMultipleChoice<T> extends AbstractChoice<Collection<?
>>>> extends T>, T>
>>>>
>>>> so that getModelObject() properly returns Collection<? extends T>
>>>> instead of the unsafe variant Collection<T>
>>>>
>>>> which, once again, will break updatemodel()
>>>>
>>>> in your experience you havent ran into a situation where a component
>>>> updates its collection model object. my experience is quiet the
>>>> opposite. just trying to make sure we do not paint ourselves into a
>>>> corner.
>>>>
>>>> -igor
>>>>
>>>> On Fri, Mar 13, 2009 at 12:31 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>>> your patch works because it does not properly refactor
>>>>> Palette#getModelCollection(). you left it us:
>>>>>
>>>>> public Collection<T> getModelCollection()
>>>>> {
>>>>> return (Collection<T>)getDefaultModelObject();
>>>>> }
>>>>>
>>>>> which is incorrect, it should in fact now return Collection<? extends
>>>>> T>, which will break Palette#updateModel()
>>>>>
>>>>> -igor
>>>>>
>>>>> On Thu, Mar 12, 2009 at 11:32 PM, James Carman
>>>>> <jc...@carmanconsulting.com> wrote:
>>>>>> FYI,
>>>>>>
>>>>>> I have created a new JIRA issue for my proposed API changes:
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/WICKET-2165
>>>>>>
>>>>>> I've attached a patch. I've "fixed" all of the places I could find
>>>>>> thus far. If I find anymore, I'll upload a new patch.
>>>>>>
>>>>>> James
>>>>>>
>>>>>> On Fri, Mar 13, 2009 at 1:59 AM, James Carman
>>>>>> <jc...@carmanconsulting.com> wrote:
>>>>>>> "Feeding" the list to your component isn't the issue (the constructor
>>>>>>> will take what you throw at it). It's using the
>>>>>>> getDefaultModelObject() method and trying to modify that list once
>>>>>>> you've passed it in that will cause you to have to cast.
>>>>>>>
>>>>>>> On Fri, Mar 13, 2009 at 1:54 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>>>>>> I'm really not sure of all the use-cases... all I know is that I spent some
>>>>>>>> time trying to get the darn thing to compile using a fairly basic wicket
>>>>>>>> pattern.
>>>>>>>>
>>>>>>>> If such a simple thing as feeding a list of items to a component that draws
>>>>>>>> a list using them is going to give me that much trouble (knowing a
>>>>>>>> workaround or not), then there is something definitely broken.
>>>>>>>>
>>>>>>>> - Brill
>>>>>>>>
>>>>>>>> On 13-Mar-09, at 1:43 AM, James Carman wrote:
>>>>>>>>
>>>>>>>>> To be clear, the only potential for breakage is where user code tries
>>>>>>>>> to modify the returned "model object" (of type List<? extends T>)
>>>>>>>>> without casting it. However, that's a rare usecase (in my opinion)
>>>>>>>>> and again it's easily overcome by a simple cast.
>>>>>>>>>
>>>>>>>>> On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg <ig...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> before applying an api-breaking patch to an rc release we should have
>>>>>>>>>> a vote on the dev list.
>>>>>>>>>>
>>>>>>>>>> -igor
>>>>>>>>>>
>>>>>>>>>> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
>>>>>>>>>> <je...@wickettraining.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Unless I'm seeing double - this patch has two problems:
>>>>>>>>>>>
>>>>>>>>>>> 1 - It is the opposite of what was voted on. The vote was to make
>>>>>>>>>>> IModel<List<? extends E>> into IModel<List<E>>. Your patch makes it
>>>>>>>>>>> IModel<? extends List<? extends E>>.
>>>>>>>>>>>
>>>>>>>>>>> 2 - The patch causes compile errors that were not fixed.
>>>>>>>>>>>
>>>>>>>>>>> I have unassigned myself from the task until those issues are addressed
>>>>>>>>>>> or I
>>>>>>>>>>> have time to create my own patch. The best solution would be for
>>>>>>>>>>> someone to
>>>>>>>>>>> submit a proper patch that fixes the two problems above or explain to me
>>>>>>>>>>> what I missed.
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Jeremy Thomerson
>>>>>>>>>>> http://www.wickettraining.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson
>>>>>>>>>>> <jeremy@wickettraining.com
>>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I'm reviewing it now. Assuming that it looks fine, and is line with
>>>>>>>>>>>> what
>>>>>>>>>>>> was proposed by the vote thread earlier, I will apply. The vote
>>>>>>>>>>>> passed, so
>>>>>>>>>>>> I don't see a reason not to. I'm not sure how many were binding /
>>>>>>>>>>>> non-binding, but there were eight for, two against.
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Jeremy Thomerson
>>>>>>>>>>>> http://www.wickettraining.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> https://issues.apache.org/jira/browse/WICKET-2137
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Brill
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by James Carman <jc...@carmanconsulting.com>.
Yes, but that's fine. The idea is that I want to collect a
List<Apple>, but I want to choose from a List<GrannySmithApple>. That
should be allowed.
On Fri, Mar 13, 2009 at 10:42 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> so then again you are back to something taking imodel<list<t>> and a
> widened version in the same constructor.
>
> -igor
>
> On Fri, Mar 13, 2009 at 3:54 AM, James Carman
> <jc...@carmanconsulting.com> wrote:
>> Again, ListMultipleChoice is okay in this instance. You don't want to
>> "widen" the model. You want to widen what can go in it (the choices),
>> which I have.
>>
>> On Fri, Mar 13, 2009 at 3:40 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>>> taking ListMultipleChoice as another example, your patch leaves it us
>>>
>>> public class ListMultipleChoice<T> extends AbstractChoice<Collection<T>, T>
>>>
>>> when in fact it should be properly declared as
>>>
>>> public class ListMultipleChoice<T> extends AbstractChoice<Collection<?
>>> extends T>, T>
>>>
>>> so that getModelObject() properly returns Collection<? extends T>
>>> instead of the unsafe variant Collection<T>
>>>
>>> which, once again, will break updatemodel()
>>>
>>> in your experience you havent ran into a situation where a component
>>> updates its collection model object. my experience is quiet the
>>> opposite. just trying to make sure we do not paint ourselves into a
>>> corner.
>>>
>>> -igor
>>>
>>> On Fri, Mar 13, 2009 at 12:31 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>> your patch works because it does not properly refactor
>>>> Palette#getModelCollection(). you left it us:
>>>>
>>>> public Collection<T> getModelCollection()
>>>> {
>>>> return (Collection<T>)getDefaultModelObject();
>>>> }
>>>>
>>>> which is incorrect, it should in fact now return Collection<? extends
>>>> T>, which will break Palette#updateModel()
>>>>
>>>> -igor
>>>>
>>>> On Thu, Mar 12, 2009 at 11:32 PM, James Carman
>>>> <jc...@carmanconsulting.com> wrote:
>>>>> FYI,
>>>>>
>>>>> I have created a new JIRA issue for my proposed API changes:
>>>>>
>>>>> https://issues.apache.org/jira/browse/WICKET-2165
>>>>>
>>>>> I've attached a patch. I've "fixed" all of the places I could find
>>>>> thus far. If I find anymore, I'll upload a new patch.
>>>>>
>>>>> James
>>>>>
>>>>> On Fri, Mar 13, 2009 at 1:59 AM, James Carman
>>>>> <jc...@carmanconsulting.com> wrote:
>>>>>> "Feeding" the list to your component isn't the issue (the constructor
>>>>>> will take what you throw at it). It's using the
>>>>>> getDefaultModelObject() method and trying to modify that list once
>>>>>> you've passed it in that will cause you to have to cast.
>>>>>>
>>>>>> On Fri, Mar 13, 2009 at 1:54 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>>>>> I'm really not sure of all the use-cases... all I know is that I spent some
>>>>>>> time trying to get the darn thing to compile using a fairly basic wicket
>>>>>>> pattern.
>>>>>>>
>>>>>>> If such a simple thing as feeding a list of items to a component that draws
>>>>>>> a list using them is going to give me that much trouble (knowing a
>>>>>>> workaround or not), then there is something definitely broken.
>>>>>>>
>>>>>>> - Brill
>>>>>>>
>>>>>>> On 13-Mar-09, at 1:43 AM, James Carman wrote:
>>>>>>>
>>>>>>>> To be clear, the only potential for breakage is where user code tries
>>>>>>>> to modify the returned "model object" (of type List<? extends T>)
>>>>>>>> without casting it. However, that's a rare usecase (in my opinion)
>>>>>>>> and again it's easily overcome by a simple cast.
>>>>>>>>
>>>>>>>> On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg <ig...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> before applying an api-breaking patch to an rc release we should have
>>>>>>>>> a vote on the dev list.
>>>>>>>>>
>>>>>>>>> -igor
>>>>>>>>>
>>>>>>>>> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
>>>>>>>>> <je...@wickettraining.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Unless I'm seeing double - this patch has two problems:
>>>>>>>>>>
>>>>>>>>>> 1 - It is the opposite of what was voted on. The vote was to make
>>>>>>>>>> IModel<List<? extends E>> into IModel<List<E>>. Your patch makes it
>>>>>>>>>> IModel<? extends List<? extends E>>.
>>>>>>>>>>
>>>>>>>>>> 2 - The patch causes compile errors that were not fixed.
>>>>>>>>>>
>>>>>>>>>> I have unassigned myself from the task until those issues are addressed
>>>>>>>>>> or I
>>>>>>>>>> have time to create my own patch. The best solution would be for
>>>>>>>>>> someone to
>>>>>>>>>> submit a proper patch that fixes the two problems above or explain to me
>>>>>>>>>> what I missed.
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Jeremy Thomerson
>>>>>>>>>> http://www.wickettraining.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson
>>>>>>>>>> <jeremy@wickettraining.com
>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> I'm reviewing it now. Assuming that it looks fine, and is line with
>>>>>>>>>>> what
>>>>>>>>>>> was proposed by the vote thread earlier, I will apply. The vote
>>>>>>>>>>> passed, so
>>>>>>>>>>> I don't see a reason not to. I'm not sure how many were binding /
>>>>>>>>>>> non-binding, but there were eight for, two against.
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Jeremy Thomerson
>>>>>>>>>>> http://www.wickettraining.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> https://issues.apache.org/jira/browse/WICKET-2137
>>>>>>>>>>>>
>>>>>>>>>>>> - Brill
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by Igor Vaynberg <ig...@gmail.com>.
so then again you are back to something taking imodel<list<t>> and a
widened version in the same constructor.
-igor
On Fri, Mar 13, 2009 at 3:54 AM, James Carman
<jc...@carmanconsulting.com> wrote:
> Again, ListMultipleChoice is okay in this instance. You don't want to
> "widen" the model. You want to widen what can go in it (the choices),
> which I have.
>
> On Fri, Mar 13, 2009 at 3:40 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>> taking ListMultipleChoice as another example, your patch leaves it us
>>
>> public class ListMultipleChoice<T> extends AbstractChoice<Collection<T>, T>
>>
>> when in fact it should be properly declared as
>>
>> public class ListMultipleChoice<T> extends AbstractChoice<Collection<?
>> extends T>, T>
>>
>> so that getModelObject() properly returns Collection<? extends T>
>> instead of the unsafe variant Collection<T>
>>
>> which, once again, will break updatemodel()
>>
>> in your experience you havent ran into a situation where a component
>> updates its collection model object. my experience is quiet the
>> opposite. just trying to make sure we do not paint ourselves into a
>> corner.
>>
>> -igor
>>
>> On Fri, Mar 13, 2009 at 12:31 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>>> your patch works because it does not properly refactor
>>> Palette#getModelCollection(). you left it us:
>>>
>>> public Collection<T> getModelCollection()
>>> {
>>> return (Collection<T>)getDefaultModelObject();
>>> }
>>>
>>> which is incorrect, it should in fact now return Collection<? extends
>>> T>, which will break Palette#updateModel()
>>>
>>> -igor
>>>
>>> On Thu, Mar 12, 2009 at 11:32 PM, James Carman
>>> <jc...@carmanconsulting.com> wrote:
>>>> FYI,
>>>>
>>>> I have created a new JIRA issue for my proposed API changes:
>>>>
>>>> https://issues.apache.org/jira/browse/WICKET-2165
>>>>
>>>> I've attached a patch. I've "fixed" all of the places I could find
>>>> thus far. If I find anymore, I'll upload a new patch.
>>>>
>>>> James
>>>>
>>>> On Fri, Mar 13, 2009 at 1:59 AM, James Carman
>>>> <jc...@carmanconsulting.com> wrote:
>>>>> "Feeding" the list to your component isn't the issue (the constructor
>>>>> will take what you throw at it). It's using the
>>>>> getDefaultModelObject() method and trying to modify that list once
>>>>> you've passed it in that will cause you to have to cast.
>>>>>
>>>>> On Fri, Mar 13, 2009 at 1:54 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>>>> I'm really not sure of all the use-cases... all I know is that I spent some
>>>>>> time trying to get the darn thing to compile using a fairly basic wicket
>>>>>> pattern.
>>>>>>
>>>>>> If such a simple thing as feeding a list of items to a component that draws
>>>>>> a list using them is going to give me that much trouble (knowing a
>>>>>> workaround or not), then there is something definitely broken.
>>>>>>
>>>>>> - Brill
>>>>>>
>>>>>> On 13-Mar-09, at 1:43 AM, James Carman wrote:
>>>>>>
>>>>>>> To be clear, the only potential for breakage is where user code tries
>>>>>>> to modify the returned "model object" (of type List<? extends T>)
>>>>>>> without casting it. However, that's a rare usecase (in my opinion)
>>>>>>> and again it's easily overcome by a simple cast.
>>>>>>>
>>>>>>> On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg <ig...@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> before applying an api-breaking patch to an rc release we should have
>>>>>>>> a vote on the dev list.
>>>>>>>>
>>>>>>>> -igor
>>>>>>>>
>>>>>>>> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
>>>>>>>> <je...@wickettraining.com> wrote:
>>>>>>>>>
>>>>>>>>> Unless I'm seeing double - this patch has two problems:
>>>>>>>>>
>>>>>>>>> 1 - It is the opposite of what was voted on. The vote was to make
>>>>>>>>> IModel<List<? extends E>> into IModel<List<E>>. Your patch makes it
>>>>>>>>> IModel<? extends List<? extends E>>.
>>>>>>>>>
>>>>>>>>> 2 - The patch causes compile errors that were not fixed.
>>>>>>>>>
>>>>>>>>> I have unassigned myself from the task until those issues are addressed
>>>>>>>>> or I
>>>>>>>>> have time to create my own patch. The best solution would be for
>>>>>>>>> someone to
>>>>>>>>> submit a proper patch that fixes the two problems above or explain to me
>>>>>>>>> what I missed.
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Jeremy Thomerson
>>>>>>>>> http://www.wickettraining.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson
>>>>>>>>> <jeremy@wickettraining.com
>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I'm reviewing it now. Assuming that it looks fine, and is line with
>>>>>>>>>> what
>>>>>>>>>> was proposed by the vote thread earlier, I will apply. The vote
>>>>>>>>>> passed, so
>>>>>>>>>> I don't see a reason not to. I'm not sure how many were binding /
>>>>>>>>>> non-binding, but there were eight for, two against.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Jeremy Thomerson
>>>>>>>>>> http://www.wickettraining.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>>>>>>>>
>>>>>>>>>>> https://issues.apache.org/jira/browse/WICKET-2137
>>>>>>>>>>>
>>>>>>>>>>> - Brill
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by James Carman <jc...@carmanconsulting.com>.
Again, ListMultipleChoice is okay in this instance. You don't want to
"widen" the model. You want to widen what can go in it (the choices),
which I have.
On Fri, Mar 13, 2009 at 3:40 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> taking ListMultipleChoice as another example, your patch leaves it us
>
> public class ListMultipleChoice<T> extends AbstractChoice<Collection<T>, T>
>
> when in fact it should be properly declared as
>
> public class ListMultipleChoice<T> extends AbstractChoice<Collection<?
> extends T>, T>
>
> so that getModelObject() properly returns Collection<? extends T>
> instead of the unsafe variant Collection<T>
>
> which, once again, will break updatemodel()
>
> in your experience you havent ran into a situation where a component
> updates its collection model object. my experience is quiet the
> opposite. just trying to make sure we do not paint ourselves into a
> corner.
>
> -igor
>
> On Fri, Mar 13, 2009 at 12:31 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>> your patch works because it does not properly refactor
>> Palette#getModelCollection(). you left it us:
>>
>> public Collection<T> getModelCollection()
>> {
>> return (Collection<T>)getDefaultModelObject();
>> }
>>
>> which is incorrect, it should in fact now return Collection<? extends
>> T>, which will break Palette#updateModel()
>>
>> -igor
>>
>> On Thu, Mar 12, 2009 at 11:32 PM, James Carman
>> <jc...@carmanconsulting.com> wrote:
>>> FYI,
>>>
>>> I have created a new JIRA issue for my proposed API changes:
>>>
>>> https://issues.apache.org/jira/browse/WICKET-2165
>>>
>>> I've attached a patch. I've "fixed" all of the places I could find
>>> thus far. If I find anymore, I'll upload a new patch.
>>>
>>> James
>>>
>>> On Fri, Mar 13, 2009 at 1:59 AM, James Carman
>>> <jc...@carmanconsulting.com> wrote:
>>>> "Feeding" the list to your component isn't the issue (the constructor
>>>> will take what you throw at it). It's using the
>>>> getDefaultModelObject() method and trying to modify that list once
>>>> you've passed it in that will cause you to have to cast.
>>>>
>>>> On Fri, Mar 13, 2009 at 1:54 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>>> I'm really not sure of all the use-cases... all I know is that I spent some
>>>>> time trying to get the darn thing to compile using a fairly basic wicket
>>>>> pattern.
>>>>>
>>>>> If such a simple thing as feeding a list of items to a component that draws
>>>>> a list using them is going to give me that much trouble (knowing a
>>>>> workaround or not), then there is something definitely broken.
>>>>>
>>>>> - Brill
>>>>>
>>>>> On 13-Mar-09, at 1:43 AM, James Carman wrote:
>>>>>
>>>>>> To be clear, the only potential for breakage is where user code tries
>>>>>> to modify the returned "model object" (of type List<? extends T>)
>>>>>> without casting it. However, that's a rare usecase (in my opinion)
>>>>>> and again it's easily overcome by a simple cast.
>>>>>>
>>>>>> On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg <ig...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> before applying an api-breaking patch to an rc release we should have
>>>>>>> a vote on the dev list.
>>>>>>>
>>>>>>> -igor
>>>>>>>
>>>>>>> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
>>>>>>> <je...@wickettraining.com> wrote:
>>>>>>>>
>>>>>>>> Unless I'm seeing double - this patch has two problems:
>>>>>>>>
>>>>>>>> 1 - It is the opposite of what was voted on. The vote was to make
>>>>>>>> IModel<List<? extends E>> into IModel<List<E>>. Your patch makes it
>>>>>>>> IModel<? extends List<? extends E>>.
>>>>>>>>
>>>>>>>> 2 - The patch causes compile errors that were not fixed.
>>>>>>>>
>>>>>>>> I have unassigned myself from the task until those issues are addressed
>>>>>>>> or I
>>>>>>>> have time to create my own patch. The best solution would be for
>>>>>>>> someone to
>>>>>>>> submit a proper patch that fixes the two problems above or explain to me
>>>>>>>> what I missed.
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jeremy Thomerson
>>>>>>>> http://www.wickettraining.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson
>>>>>>>> <jeremy@wickettraining.com
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I'm reviewing it now. Assuming that it looks fine, and is line with
>>>>>>>>> what
>>>>>>>>> was proposed by the vote thread earlier, I will apply. The vote
>>>>>>>>> passed, so
>>>>>>>>> I don't see a reason not to. I'm not sure how many were binding /
>>>>>>>>> non-binding, but there were eight for, two against.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Jeremy Thomerson
>>>>>>>>> http://www.wickettraining.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>>>>>>>
>>>>>>>>>> https://issues.apache.org/jira/browse/WICKET-2137
>>>>>>>>>>
>>>>>>>>>> - Brill
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by Igor Vaynberg <ig...@gmail.com>.
taking ListMultipleChoice as another example, your patch leaves it us
public class ListMultipleChoice<T> extends AbstractChoice<Collection<T>, T>
when in fact it should be properly declared as
public class ListMultipleChoice<T> extends AbstractChoice<Collection<?
extends T>, T>
so that getModelObject() properly returns Collection<? extends T>
instead of the unsafe variant Collection<T>
which, once again, will break updatemodel()
in your experience you havent ran into a situation where a component
updates its collection model object. my experience is quiet the
opposite. just trying to make sure we do not paint ourselves into a
corner.
-igor
On Fri, Mar 13, 2009 at 12:31 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> your patch works because it does not properly refactor
> Palette#getModelCollection(). you left it us:
>
> public Collection<T> getModelCollection()
> {
> return (Collection<T>)getDefaultModelObject();
> }
>
> which is incorrect, it should in fact now return Collection<? extends
> T>, which will break Palette#updateModel()
>
> -igor
>
> On Thu, Mar 12, 2009 at 11:32 PM, James Carman
> <jc...@carmanconsulting.com> wrote:
>> FYI,
>>
>> I have created a new JIRA issue for my proposed API changes:
>>
>> https://issues.apache.org/jira/browse/WICKET-2165
>>
>> I've attached a patch. I've "fixed" all of the places I could find
>> thus far. If I find anymore, I'll upload a new patch.
>>
>> James
>>
>> On Fri, Mar 13, 2009 at 1:59 AM, James Carman
>> <jc...@carmanconsulting.com> wrote:
>>> "Feeding" the list to your component isn't the issue (the constructor
>>> will take what you throw at it). It's using the
>>> getDefaultModelObject() method and trying to modify that list once
>>> you've passed it in that will cause you to have to cast.
>>>
>>> On Fri, Mar 13, 2009 at 1:54 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>> I'm really not sure of all the use-cases... all I know is that I spent some
>>>> time trying to get the darn thing to compile using a fairly basic wicket
>>>> pattern.
>>>>
>>>> If such a simple thing as feeding a list of items to a component that draws
>>>> a list using them is going to give me that much trouble (knowing a
>>>> workaround or not), then there is something definitely broken.
>>>>
>>>> - Brill
>>>>
>>>> On 13-Mar-09, at 1:43 AM, James Carman wrote:
>>>>
>>>>> To be clear, the only potential for breakage is where user code tries
>>>>> to modify the returned "model object" (of type List<? extends T>)
>>>>> without casting it. However, that's a rare usecase (in my opinion)
>>>>> and again it's easily overcome by a simple cast.
>>>>>
>>>>> On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg <ig...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> before applying an api-breaking patch to an rc release we should have
>>>>>> a vote on the dev list.
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
>>>>>> <je...@wickettraining.com> wrote:
>>>>>>>
>>>>>>> Unless I'm seeing double - this patch has two problems:
>>>>>>>
>>>>>>> 1 - It is the opposite of what was voted on. The vote was to make
>>>>>>> IModel<List<? extends E>> into IModel<List<E>>. Your patch makes it
>>>>>>> IModel<? extends List<? extends E>>.
>>>>>>>
>>>>>>> 2 - The patch causes compile errors that were not fixed.
>>>>>>>
>>>>>>> I have unassigned myself from the task until those issues are addressed
>>>>>>> or I
>>>>>>> have time to create my own patch. The best solution would be for
>>>>>>> someone to
>>>>>>> submit a proper patch that fixes the two problems above or explain to me
>>>>>>> what I missed.
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> --
>>>>>>> Jeremy Thomerson
>>>>>>> http://www.wickettraining.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson
>>>>>>> <jeremy@wickettraining.com
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>
>>>>>>>> I'm reviewing it now. Assuming that it looks fine, and is line with
>>>>>>>> what
>>>>>>>> was proposed by the vote thread earlier, I will apply. The vote
>>>>>>>> passed, so
>>>>>>>> I don't see a reason not to. I'm not sure how many were binding /
>>>>>>>> non-binding, but there were eight for, two against.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jeremy Thomerson
>>>>>>>> http://www.wickettraining.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>>>>>>
>>>>>>>>> https://issues.apache.org/jira/browse/WICKET-2137
>>>>>>>>>
>>>>>>>>> - Brill
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by James Carman <jc...@carmanconsulting.com>.
Your right, my patch was a bit off with respect to Palette, but not
because of this. I shouldn't have "widened" the second constructor.
It should take a IModel<List<T>>. So, the getModelCollection()
doesn't have to change. When we're doing this widening, only the
"choices" (not the model) should be widened.
On Fri, Mar 13, 2009 at 3:31 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> your patch works because it does not properly refactor
> Palette#getModelCollection(). you left it us:
>
> public Collection<T> getModelCollection()
> {
> return (Collection<T>)getDefaultModelObject();
> }
>
> which is incorrect, it should in fact now return Collection<? extends
> T>, which will break Palette#updateModel()
>
> -igor
>
> On Thu, Mar 12, 2009 at 11:32 PM, James Carman
> <jc...@carmanconsulting.com> wrote:
>> FYI,
>>
>> I have created a new JIRA issue for my proposed API changes:
>>
>> https://issues.apache.org/jira/browse/WICKET-2165
>>
>> I've attached a patch. I've "fixed" all of the places I could find
>> thus far. If I find anymore, I'll upload a new patch.
>>
>> James
>>
>> On Fri, Mar 13, 2009 at 1:59 AM, James Carman
>> <jc...@carmanconsulting.com> wrote:
>>> "Feeding" the list to your component isn't the issue (the constructor
>>> will take what you throw at it). It's using the
>>> getDefaultModelObject() method and trying to modify that list once
>>> you've passed it in that will cause you to have to cast.
>>>
>>> On Fri, Mar 13, 2009 at 1:54 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>> I'm really not sure of all the use-cases... all I know is that I spent some
>>>> time trying to get the darn thing to compile using a fairly basic wicket
>>>> pattern.
>>>>
>>>> If such a simple thing as feeding a list of items to a component that draws
>>>> a list using them is going to give me that much trouble (knowing a
>>>> workaround or not), then there is something definitely broken.
>>>>
>>>> - Brill
>>>>
>>>> On 13-Mar-09, at 1:43 AM, James Carman wrote:
>>>>
>>>>> To be clear, the only potential for breakage is where user code tries
>>>>> to modify the returned "model object" (of type List<? extends T>)
>>>>> without casting it. However, that's a rare usecase (in my opinion)
>>>>> and again it's easily overcome by a simple cast.
>>>>>
>>>>> On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg <ig...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> before applying an api-breaking patch to an rc release we should have
>>>>>> a vote on the dev list.
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
>>>>>> <je...@wickettraining.com> wrote:
>>>>>>>
>>>>>>> Unless I'm seeing double - this patch has two problems:
>>>>>>>
>>>>>>> 1 - It is the opposite of what was voted on. The vote was to make
>>>>>>> IModel<List<? extends E>> into IModel<List<E>>. Your patch makes it
>>>>>>> IModel<? extends List<? extends E>>.
>>>>>>>
>>>>>>> 2 - The patch causes compile errors that were not fixed.
>>>>>>>
>>>>>>> I have unassigned myself from the task until those issues are addressed
>>>>>>> or I
>>>>>>> have time to create my own patch. The best solution would be for
>>>>>>> someone to
>>>>>>> submit a proper patch that fixes the two problems above or explain to me
>>>>>>> what I missed.
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> --
>>>>>>> Jeremy Thomerson
>>>>>>> http://www.wickettraining.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson
>>>>>>> <jeremy@wickettraining.com
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>
>>>>>>>> I'm reviewing it now. Assuming that it looks fine, and is line with
>>>>>>>> what
>>>>>>>> was proposed by the vote thread earlier, I will apply. The vote
>>>>>>>> passed, so
>>>>>>>> I don't see a reason not to. I'm not sure how many were binding /
>>>>>>>> non-binding, but there were eight for, two against.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jeremy Thomerson
>>>>>>>> http://www.wickettraining.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>>>>>>
>>>>>>>>> https://issues.apache.org/jira/browse/WICKET-2137
>>>>>>>>>
>>>>>>>>> - Brill
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by Igor Vaynberg <ig...@gmail.com>.
your patch works because it does not properly refactor
Palette#getModelCollection(). you left it us:
public Collection<T> getModelCollection()
{
return (Collection<T>)getDefaultModelObject();
}
which is incorrect, it should in fact now return Collection<? extends
T>, which will break Palette#updateModel()
-igor
On Thu, Mar 12, 2009 at 11:32 PM, James Carman
<jc...@carmanconsulting.com> wrote:
> FYI,
>
> I have created a new JIRA issue for my proposed API changes:
>
> https://issues.apache.org/jira/browse/WICKET-2165
>
> I've attached a patch. I've "fixed" all of the places I could find
> thus far. If I find anymore, I'll upload a new patch.
>
> James
>
> On Fri, Mar 13, 2009 at 1:59 AM, James Carman
> <jc...@carmanconsulting.com> wrote:
>> "Feeding" the list to your component isn't the issue (the constructor
>> will take what you throw at it). It's using the
>> getDefaultModelObject() method and trying to modify that list once
>> you've passed it in that will cause you to have to cast.
>>
>> On Fri, Mar 13, 2009 at 1:54 AM, Brill Pappin <br...@pappin.ca> wrote:
>>> I'm really not sure of all the use-cases... all I know is that I spent some
>>> time trying to get the darn thing to compile using a fairly basic wicket
>>> pattern.
>>>
>>> If such a simple thing as feeding a list of items to a component that draws
>>> a list using them is going to give me that much trouble (knowing a
>>> workaround or not), then there is something definitely broken.
>>>
>>> - Brill
>>>
>>> On 13-Mar-09, at 1:43 AM, James Carman wrote:
>>>
>>>> To be clear, the only potential for breakage is where user code tries
>>>> to modify the returned "model object" (of type List<? extends T>)
>>>> without casting it. However, that's a rare usecase (in my opinion)
>>>> and again it's easily overcome by a simple cast.
>>>>
>>>> On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg <ig...@gmail.com>
>>>> wrote:
>>>>>
>>>>> before applying an api-breaking patch to an rc release we should have
>>>>> a vote on the dev list.
>>>>>
>>>>> -igor
>>>>>
>>>>> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
>>>>> <je...@wickettraining.com> wrote:
>>>>>>
>>>>>> Unless I'm seeing double - this patch has two problems:
>>>>>>
>>>>>> 1 - It is the opposite of what was voted on. The vote was to make
>>>>>> IModel<List<? extends E>> into IModel<List<E>>. Your patch makes it
>>>>>> IModel<? extends List<? extends E>>.
>>>>>>
>>>>>> 2 - The patch causes compile errors that were not fixed.
>>>>>>
>>>>>> I have unassigned myself from the task until those issues are addressed
>>>>>> or I
>>>>>> have time to create my own patch. The best solution would be for
>>>>>> someone to
>>>>>> submit a proper patch that fixes the two problems above or explain to me
>>>>>> what I missed.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> --
>>>>>> Jeremy Thomerson
>>>>>> http://www.wickettraining.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson
>>>>>> <jeremy@wickettraining.com
>>>>>>>
>>>>>>> wrote:
>>>>>>
>>>>>>> I'm reviewing it now. Assuming that it looks fine, and is line with
>>>>>>> what
>>>>>>> was proposed by the vote thread earlier, I will apply. The vote
>>>>>>> passed, so
>>>>>>> I don't see a reason not to. I'm not sure how many were binding /
>>>>>>> non-binding, but there were eight for, two against.
>>>>>>>
>>>>>>> --
>>>>>>> Jeremy Thomerson
>>>>>>> http://www.wickettraining.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>>>>>
>>>>>>>> https://issues.apache.org/jira/browse/WICKET-2137
>>>>>>>>
>>>>>>>> - Brill
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by James Carman <jc...@carmanconsulting.com>.
FYI,
I have created a new JIRA issue for my proposed API changes:
https://issues.apache.org/jira/browse/WICKET-2165
I've attached a patch. I've "fixed" all of the places I could find
thus far. If I find anymore, I'll upload a new patch.
James
On Fri, Mar 13, 2009 at 1:59 AM, James Carman
<jc...@carmanconsulting.com> wrote:
> "Feeding" the list to your component isn't the issue (the constructor
> will take what you throw at it). It's using the
> getDefaultModelObject() method and trying to modify that list once
> you've passed it in that will cause you to have to cast.
>
> On Fri, Mar 13, 2009 at 1:54 AM, Brill Pappin <br...@pappin.ca> wrote:
>> I'm really not sure of all the use-cases... all I know is that I spent some
>> time trying to get the darn thing to compile using a fairly basic wicket
>> pattern.
>>
>> If such a simple thing as feeding a list of items to a component that draws
>> a list using them is going to give me that much trouble (knowing a
>> workaround or not), then there is something definitely broken.
>>
>> - Brill
>>
>> On 13-Mar-09, at 1:43 AM, James Carman wrote:
>>
>>> To be clear, the only potential for breakage is where user code tries
>>> to modify the returned "model object" (of type List<? extends T>)
>>> without casting it. However, that's a rare usecase (in my opinion)
>>> and again it's easily overcome by a simple cast.
>>>
>>> On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg <ig...@gmail.com>
>>> wrote:
>>>>
>>>> before applying an api-breaking patch to an rc release we should have
>>>> a vote on the dev list.
>>>>
>>>> -igor
>>>>
>>>> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
>>>> <je...@wickettraining.com> wrote:
>>>>>
>>>>> Unless I'm seeing double - this patch has two problems:
>>>>>
>>>>> 1 - It is the opposite of what was voted on. The vote was to make
>>>>> IModel<List<? extends E>> into IModel<List<E>>. Your patch makes it
>>>>> IModel<? extends List<? extends E>>.
>>>>>
>>>>> 2 - The patch causes compile errors that were not fixed.
>>>>>
>>>>> I have unassigned myself from the task until those issues are addressed
>>>>> or I
>>>>> have time to create my own patch. The best solution would be for
>>>>> someone to
>>>>> submit a proper patch that fixes the two problems above or explain to me
>>>>> what I missed.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> --
>>>>> Jeremy Thomerson
>>>>> http://www.wickettraining.com
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson
>>>>> <jeremy@wickettraining.com
>>>>>>
>>>>>> wrote:
>>>>>
>>>>>> I'm reviewing it now. Assuming that it looks fine, and is line with
>>>>>> what
>>>>>> was proposed by the vote thread earlier, I will apply. The vote
>>>>>> passed, so
>>>>>> I don't see a reason not to. I'm not sure how many were binding /
>>>>>> non-binding, but there were eight for, two against.
>>>>>>
>>>>>> --
>>>>>> Jeremy Thomerson
>>>>>> http://www.wickettraining.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>>>>
>>>>>>> https://issues.apache.org/jira/browse/WICKET-2137
>>>>>>>
>>>>>>> - Brill
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by James Carman <jc...@carmanconsulting.com>.
"Feeding" the list to your component isn't the issue (the constructor
will take what you throw at it). It's using the
getDefaultModelObject() method and trying to modify that list once
you've passed it in that will cause you to have to cast.
On Fri, Mar 13, 2009 at 1:54 AM, Brill Pappin <br...@pappin.ca> wrote:
> I'm really not sure of all the use-cases... all I know is that I spent some
> time trying to get the darn thing to compile using a fairly basic wicket
> pattern.
>
> If such a simple thing as feeding a list of items to a component that draws
> a list using them is going to give me that much trouble (knowing a
> workaround or not), then there is something definitely broken.
>
> - Brill
>
> On 13-Mar-09, at 1:43 AM, James Carman wrote:
>
>> To be clear, the only potential for breakage is where user code tries
>> to modify the returned "model object" (of type List<? extends T>)
>> without casting it. However, that's a rare usecase (in my opinion)
>> and again it's easily overcome by a simple cast.
>>
>> On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg <ig...@gmail.com>
>> wrote:
>>>
>>> before applying an api-breaking patch to an rc release we should have
>>> a vote on the dev list.
>>>
>>> -igor
>>>
>>> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
>>> <je...@wickettraining.com> wrote:
>>>>
>>>> Unless I'm seeing double - this patch has two problems:
>>>>
>>>> 1 - It is the opposite of what was voted on. The vote was to make
>>>> IModel<List<? extends E>> into IModel<List<E>>. Your patch makes it
>>>> IModel<? extends List<? extends E>>.
>>>>
>>>> 2 - The patch causes compile errors that were not fixed.
>>>>
>>>> I have unassigned myself from the task until those issues are addressed
>>>> or I
>>>> have time to create my own patch. The best solution would be for
>>>> someone to
>>>> submit a proper patch that fixes the two problems above or explain to me
>>>> what I missed.
>>>>
>>>> Thanks!
>>>>
>>>> --
>>>> Jeremy Thomerson
>>>> http://www.wickettraining.com
>>>>
>>>>
>>>>
>>>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson
>>>> <jeremy@wickettraining.com
>>>>>
>>>>> wrote:
>>>>
>>>>> I'm reviewing it now. Assuming that it looks fine, and is line with
>>>>> what
>>>>> was proposed by the vote thread earlier, I will apply. The vote
>>>>> passed, so
>>>>> I don't see a reason not to. I'm not sure how many were binding /
>>>>> non-binding, but there were eight for, two against.
>>>>>
>>>>> --
>>>>> Jeremy Thomerson
>>>>> http://www.wickettraining.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>>>
>>>>>> https://issues.apache.org/jira/browse/WICKET-2137
>>>>>>
>>>>>> - Brill
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by Brill Pappin <br...@pappin.ca>.
I'm really not sure of all the use-cases... all I know is that I spent
some time trying to get the darn thing to compile using a fairly basic
wicket pattern.
If such a simple thing as feeding a list of items to a component that
draws a list using them is going to give me that much trouble (knowing
a workaround or not), then there is something definitely broken.
- Brill
On 13-Mar-09, at 1:43 AM, James Carman wrote:
> To be clear, the only potential for breakage is where user code tries
> to modify the returned "model object" (of type List<? extends T>)
> without casting it. However, that's a rare usecase (in my opinion)
> and again it's easily overcome by a simple cast.
>
> On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg <igor.vaynberg@gmail.com
> > wrote:
>> before applying an api-breaking patch to an rc release we should have
>> a vote on the dev list.
>>
>> -igor
>>
>> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
>> <je...@wickettraining.com> wrote:
>>> Unless I'm seeing double - this patch has two problems:
>>>
>>> 1 - It is the opposite of what was voted on. The vote was to make
>>> IModel<List<? extends E>> into IModel<List<E>>. Your patch makes it
>>> IModel<? extends List<? extends E>>.
>>>
>>> 2 - The patch causes compile errors that were not fixed.
>>>
>>> I have unassigned myself from the task until those issues are
>>> addressed or I
>>> have time to create my own patch. The best solution would be for
>>> someone to
>>> submit a proper patch that fixes the two problems above or explain
>>> to me
>>> what I missed.
>>>
>>> Thanks!
>>>
>>> --
>>> Jeremy Thomerson
>>> http://www.wickettraining.com
>>>
>>>
>>>
>>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson <jeremy@wickettraining.com
>>>> wrote:
>>>
>>>> I'm reviewing it now. Assuming that it looks fine, and is line
>>>> with what
>>>> was proposed by the vote thread earlier, I will apply. The vote
>>>> passed, so
>>>> I don't see a reason not to. I'm not sure how many were binding /
>>>> non-binding, but there were eight for, two against.
>>>>
>>>> --
>>>> Jeremy Thomerson
>>>> http://www.wickettraining.com
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin <br...@pappin.ca>
>>>> wrote:
>>>>
>>>>> https://issues.apache.org/jira/browse/WICKET-2137
>>>>>
>>>>> - Brill
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by James Carman <jc...@carmanconsulting.com>.
To be clear, the only potential for breakage is where user code tries
to modify the returned "model object" (of type List<? extends T>)
without casting it. However, that's a rare usecase (in my opinion)
and again it's easily overcome by a simple cast.
On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> before applying an api-breaking patch to an rc release we should have
> a vote on the dev list.
>
> -igor
>
> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
> <je...@wickettraining.com> wrote:
>> Unless I'm seeing double - this patch has two problems:
>>
>> 1 - It is the opposite of what was voted on. The vote was to make
>> IModel<List<? extends E>> into IModel<List<E>>. Your patch makes it
>> IModel<? extends List<? extends E>>.
>>
>> 2 - The patch causes compile errors that were not fixed.
>>
>> I have unassigned myself from the task until those issues are addressed or I
>> have time to create my own patch. The best solution would be for someone to
>> submit a proper patch that fixes the two problems above or explain to me
>> what I missed.
>>
>> Thanks!
>>
>> --
>> Jeremy Thomerson
>> http://www.wickettraining.com
>>
>>
>>
>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson <jeremy@wickettraining.com
>>> wrote:
>>
>>> I'm reviewing it now. Assuming that it looks fine, and is line with what
>>> was proposed by the vote thread earlier, I will apply. The vote passed, so
>>> I don't see a reason not to. I'm not sure how many were binding /
>>> non-binding, but there were eight for, two against.
>>>
>>> --
>>> Jeremy Thomerson
>>> http://www.wickettraining.com
>>>
>>>
>>>
>>>
>>> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>
>>>> https://issues.apache.org/jira/browse/WICKET-2137
>>>>
>>>> - Brill
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by Brill Pappin <br...@pappin.ca>.
Sorry, didn't mean to come off accusing :)
That was certainly the vote thread, and my personal preference as
well...
However in the issue I was assured that the new approach was better
and compatible with List<T> (I did not test it myself).
I think this is certainly something the developers are going to have
to review, and you will know best which way it should go based on the
amount of work and compatibility with the existing code-base.
The issue has some discussion and examples about the two methods.
- Brill
On 13-Mar-09, at 1:02 AM, Jeremy Thomerson wrote:
> Right - I didn't read the entire series of comments on the JIRA. I
> did read
> one that explained why removing the "? extends" was the best
> solution, and
> several that agreed with it. I am basing my comments on the vote
> thread
> that was on the user list - a change like this will require a vote
> (as Igor
> pointed out) - so I won't commit something like this that is not in
> line
> with what was voted for.
>
> My vote is still that removing the "? extends" is better from my
> personal
> experience - but I don't have a vested interest in whether it makes
> it into
> the 1.4 release. While it may be beneficial, it would be out of the
> ordinary to introduce an API break after we're already to release
> candidate
> phase.
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
>
> On Thu, Mar 12, 2009 at 11:56 PM, Brill Pappin <br...@pappin.ca>
> wrote:
>
>> This is an attempt to bring the dropdown and listview into sync.
>> personally i don't care which way it goes as long as its simple and
>> works,
>> but I think it pretty important that it be done before the 1.4
>> release.
>>
>> The discussion was continued in the issue, so it's possible that
>> people
>> were not watching it or voting on it there. I think Jeremy didn't
>> have time
>> to actually read the issue all the way through or he would have
>> seen why the
>> patch was the way it was.
>>
>> I would like to invite anyone with interest to take a look at:
>> https://issues.apache.org/jira/browse/WICKET-2137
>>
>> By all means, add your thoughts... as a user of wicket, I certainly
>> *do*
>> want to to see this make it into the 1.4 release.
>>
>> - Brill
>>
>>
>> On 12-Mar-09, at 5:10 PM, Igor Vaynberg wrote:
>>
>> before applying an api-breaking patch to an rc release we should have
>>> a vote on the dev list.
>>>
>>> -igor
>>>
>>> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
>>> <je...@wickettraining.com> wrote:
>>>
>>>> Unless I'm seeing double - this patch has two problems:
>>>>
>>>> 1 - It is the opposite of what was voted on. The vote was to make
>>>> IModel<List<? extends E>> into IModel<List<E>>. Your patch makes
>>>> it
>>>> IModel<? extends List<? extends E>>.
>>>>
>>>> 2 - The patch causes compile errors that were not fixed.
>>>>
>>>> I have unassigned myself from the task until those issues are
>>>> addressed
>>>> or I
>>>> have time to create my own patch. The best solution would be for
>>>> someone
>>>> to
>>>> submit a proper patch that fixes the two problems above or
>>>> explain to me
>>>> what I missed.
>>>>
>>>> Thanks!
>>>>
>>>> --
>>>> Jeremy Thomerson
>>>> http://www.wickettraining.com
>>>>
>>>>
>>>>
>>>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson <
>>>> jeremy@wickettraining.com
>>>>
>>>>> wrote:
>>>>>
>>>>
>>>> I'm reviewing it now. Assuming that it looks fine, and is line
>>>> with
>>>>> what
>>>>> was proposed by the vote thread earlier, I will apply. The vote
>>>>> passed,
>>>>> so
>>>>> I don't see a reason not to. I'm not sure how many were binding /
>>>>> non-binding, but there were eight for, two against.
>>>>>
>>>>> --
>>>>> Jeremy Thomerson
>>>>> http://www.wickettraining.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin <br...@pappin.ca>
>>>>> wrote:
>>>>>
>>>>> https://issues.apache.org/jira/browse/WICKET-2137
>>>>>>
>>>>>> - Brill
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by Jeremy Thomerson <je...@wickettraining.com>.
Right - I didn't read the entire series of comments on the JIRA. I did read
one that explained why removing the "? extends" was the best solution, and
several that agreed with it. I am basing my comments on the vote thread
that was on the user list - a change like this will require a vote (as Igor
pointed out) - so I won't commit something like this that is not in line
with what was voted for.
My vote is still that removing the "? extends" is better from my personal
experience - but I don't have a vested interest in whether it makes it into
the 1.4 release. While it may be beneficial, it would be out of the
ordinary to introduce an API break after we're already to release candidate
phase.
--
Jeremy Thomerson
http://www.wickettraining.com
On Thu, Mar 12, 2009 at 11:56 PM, Brill Pappin <br...@pappin.ca> wrote:
> This is an attempt to bring the dropdown and listview into sync.
> personally i don't care which way it goes as long as its simple and works,
> but I think it pretty important that it be done before the 1.4 release.
>
> The discussion was continued in the issue, so it's possible that people
> were not watching it or voting on it there. I think Jeremy didn't have time
> to actually read the issue all the way through or he would have seen why the
> patch was the way it was.
>
> I would like to invite anyone with interest to take a look at:
> https://issues.apache.org/jira/browse/WICKET-2137
>
> By all means, add your thoughts... as a user of wicket, I certainly *do*
> want to to see this make it into the 1.4 release.
>
> - Brill
>
>
> On 12-Mar-09, at 5:10 PM, Igor Vaynberg wrote:
>
> before applying an api-breaking patch to an rc release we should have
>> a vote on the dev list.
>>
>> -igor
>>
>> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
>> <je...@wickettraining.com> wrote:
>>
>>> Unless I'm seeing double - this patch has two problems:
>>>
>>> 1 - It is the opposite of what was voted on. The vote was to make
>>> IModel<List<? extends E>> into IModel<List<E>>. Your patch makes it
>>> IModel<? extends List<? extends E>>.
>>>
>>> 2 - The patch causes compile errors that were not fixed.
>>>
>>> I have unassigned myself from the task until those issues are addressed
>>> or I
>>> have time to create my own patch. The best solution would be for someone
>>> to
>>> submit a proper patch that fixes the two problems above or explain to me
>>> what I missed.
>>>
>>> Thanks!
>>>
>>> --
>>> Jeremy Thomerson
>>> http://www.wickettraining.com
>>>
>>>
>>>
>>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson <
>>> jeremy@wickettraining.com
>>>
>>>> wrote:
>>>>
>>>
>>> I'm reviewing it now. Assuming that it looks fine, and is line with
>>>> what
>>>> was proposed by the vote thread earlier, I will apply. The vote passed,
>>>> so
>>>> I don't see a reason not to. I'm not sure how many were binding /
>>>> non-binding, but there were eight for, two against.
>>>>
>>>> --
>>>> Jeremy Thomerson
>>>> http://www.wickettraining.com
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin <br...@pappin.ca> wrote:
>>>>
>>>> https://issues.apache.org/jira/browse/WICKET-2137
>>>>>
>>>>> - Brill
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: can we get this patch applied to the current snapshot?
Posted by Brill Pappin <br...@pappin.ca>.
This is an attempt to bring the dropdown and listview into sync.
personally i don't care which way it goes as long as its simple and
works, but I think it pretty important that it be done before the 1.4
release.
The discussion was continued in the issue, so it's possible that
people were not watching it or voting on it there. I think Jeremy
didn't have time to actually read the issue all the way through or he
would have seen why the patch was the way it was.
I would like to invite anyone with interest to take a look at:
https://issues.apache.org/jira/browse/WICKET-2137
By all means, add your thoughts... as a user of wicket, I certainly
*do* want to to see this make it into the 1.4 release.
- Brill
On 12-Mar-09, at 5:10 PM, Igor Vaynberg wrote:
> before applying an api-breaking patch to an rc release we should have
> a vote on the dev list.
>
> -igor
>
> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
> <je...@wickettraining.com> wrote:
>> Unless I'm seeing double - this patch has two problems:
>>
>> 1 - It is the opposite of what was voted on. The vote was to make
>> IModel<List<? extends E>> into IModel<List<E>>. Your patch makes it
>> IModel<? extends List<? extends E>>.
>>
>> 2 - The patch causes compile errors that were not fixed.
>>
>> I have unassigned myself from the task until those issues are
>> addressed or I
>> have time to create my own patch. The best solution would be for
>> someone to
>> submit a proper patch that fixes the two problems above or explain
>> to me
>> what I missed.
>>
>> Thanks!
>>
>> --
>> Jeremy Thomerson
>> http://www.wickettraining.com
>>
>>
>>
>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson <jeremy@wickettraining.com
>>> wrote:
>>
>>> I'm reviewing it now. Assuming that it looks fine, and is line
>>> with what
>>> was proposed by the vote thread earlier, I will apply. The vote
>>> passed, so
>>> I don't see a reason not to. I'm not sure how many were binding /
>>> non-binding, but there were eight for, two against.
>>>
>>> --
>>> Jeremy Thomerson
>>> http://www.wickettraining.com
>>>
>>>
>>>
>>>
>>> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin <br...@pappin.ca>
>>> wrote:
>>>
>>>> https://issues.apache.org/jira/browse/WICKET-2137
>>>>
>>>> - Brill
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by Igor Vaynberg <ig...@gmail.com>.
before applying an api-breaking patch to an rc release we should have
a vote on the dev list.
-igor
On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
<je...@wickettraining.com> wrote:
> Unless I'm seeing double - this patch has two problems:
>
> 1 - It is the opposite of what was voted on. The vote was to make
> IModel<List<? extends E>> into IModel<List<E>>. Your patch makes it
> IModel<? extends List<? extends E>>.
>
> 2 - The patch causes compile errors that were not fixed.
>
> I have unassigned myself from the task until those issues are addressed or I
> have time to create my own patch. The best solution would be for someone to
> submit a proper patch that fixes the two problems above or explain to me
> what I missed.
>
> Thanks!
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
>
> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson <jeremy@wickettraining.com
>> wrote:
>
>> I'm reviewing it now. Assuming that it looks fine, and is line with what
>> was proposed by the vote thread earlier, I will apply. The vote passed, so
>> I don't see a reason not to. I'm not sure how many were binding /
>> non-binding, but there were eight for, two against.
>>
>> --
>> Jeremy Thomerson
>> http://www.wickettraining.com
>>
>>
>>
>>
>> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin <br...@pappin.ca> wrote:
>>
>>> https://issues.apache.org/jira/browse/WICKET-2137
>>>
>>> - Brill
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Posted by Jeremy Thomerson <je...@wickettraining.com>.
Unless I'm seeing double - this patch has two problems:
1 - It is the opposite of what was voted on. The vote was to make
IModel<List<? extends E>> into IModel<List<E>>. Your patch makes it
IModel<? extends List<? extends E>>.
2 - The patch causes compile errors that were not fixed.
I have unassigned myself from the task until those issues are addressed or I
have time to create my own patch. The best solution would be for someone to
submit a proper patch that fixes the two problems above or explain to me
what I missed.
Thanks!
--
Jeremy Thomerson
http://www.wickettraining.com
On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson <jeremy@wickettraining.com
> wrote:
> I'm reviewing it now. Assuming that it looks fine, and is line with what
> was proposed by the vote thread earlier, I will apply. The vote passed, so
> I don't see a reason not to. I'm not sure how many were binding /
> non-binding, but there were eight for, two against.
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
>
>
> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin <br...@pappin.ca> wrote:
>
>> https://issues.apache.org/jira/browse/WICKET-2137
>>
>> - Brill
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
Re: can we get this patch applied to the current snapshot?
Posted by Jeremy Thomerson <je...@wickettraining.com>.
I'm reviewing it now. Assuming that it looks fine, and is line with what
was proposed by the vote thread earlier, I will apply. The vote passed, so
I don't see a reason not to. I'm not sure how many were binding /
non-binding, but there were eight for, two against.
--
Jeremy Thomerson
http://www.wickettraining.com
On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin <br...@pappin.ca> wrote:
> https://issues.apache.org/jira/browse/WICKET-2137
>
> - Brill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>