See the sample test in ticket: WICKET-2137
https://issues.apache.org/jira/browse/WICKET-2137
- brill
On 4-Mar-09, at 11:08 AM, Johannes Schneider wrote:
On Wed, 2009-03-04 at 10:04 -0500, Brill Pappin wrote:
I actually wasn't saying they were the same.
What I said (meant) was that:
a) don't lock down
Locking down means *removing* the wildcard. Adding the wildcard
*widens*
the collection.
To be clear:
Wildcard --> it fits for everybody
No wildcard --> it fits only for some special cases (maybe yours)
b) I prefer the explicit form rather than the "Any of type" form.
i.e.
<List<T>> rather than <List<? extends T>>.
They mean something completely different. I understand that you prefer
the shorter version. Many do. But it stays wrong...
If the constructor accepts "List<Number>", everybody *has* to give you
exactly a List<Number>.
List<Number> n = new List<Number>;
If the constructor accepts the widened type, you can add all those
lists...
List<? extends Number> n = new List<Number>;
List<? extends Number> n = new List<Integer>;
List<? extends Number> n = new List<Double>;
If you don't believe me, take a look at GlazedLists. Compare version
1.7
and version 1.8. They changed exactly that thing (a non backward
compatible change!). They made exactly the same fault...
Regards,
Johannes
- Brill
On 4-Mar-09, at 6:26 AM, Johannes Schneider wrote:
On Tue, 2009-03-03 at 16:02 -0500, Brill Pappin wrote:
I'd hate to be
prevented from doing so simply because someone wanted to lock
down an
API that didn't really need locking down.
You are wrong. *Widening* a collection is the exact opposite of
"locking
down".
If you want to have some fancy (read "hacky") write access to the
model
you are free to simply cast...
That is the right choice here. You know that you have a special
model in
there, so cast it.
But the "common" case is, that you don't know for sure whether the
model
supports adding of choices or not.
If you don't believe me, take a look at JComboBox.
javax.swing.JComboBox#getModel returns a *read only* view of the
model.
Regards,
Johannes
I think the syntax doesn't really mean read only, and if the wicket
developers really want it to be read only, wrapping the list
would be
the way to go.
I'm for the plain old <List<T>> because its simple and explicit...
<List<? extends T>> would be my next choice because it widens the
scope.
- Brill
On 2-Mar-09, at 3:44 PM, James Carman wrote:
Aren't both the "choices" model in DDC and the actual model of
ListView supposed to be considered read-only (as far as the
component
is concerned)? The DDC and ListView don't need to be able to
alter
those models anyway, right? Perhaps my experience is just too
limited, but I don't think I've ever tried to do either one of
your
usecases (I always consider them read-only).
On Mon, Mar 2, 2009 at 3:24 PM, Igor Vaynberg
<igor.vaynb...@gmail.com> wrote:
see WICKET-2126
-igor
On Mon, Mar 2, 2009 at 12:19 PM, James Carman
<jcar...@carmanconsulting.com> wrote:
I vote -0.99 on this (non-binding of course). I'd vote +1 to
making
ListView accept List<? extends T> rather than making DDC less
flexible.
On Mon, Mar 2, 2009 at 3:11 PM, Brill Pappin <br...@pappin.ca>
wrote:
Ok, as suggested, here is the thread, and the first vote.
+1
for making the generic definition the same for all list type
components.
FYI - you can also "vote" in the issue I just created at
(which
might
actually be a better place to vote):
https://issues.apache.org/jira/browse/WICKET-2137
- Brill
On 28-Feb-09, at 5:18 PM, Jeremy Thomerson wrote:
Perhaps start a vote thread, with the subject something like:
"VOTE:
Remove
? extends from constructor of DropDownChoice".
I'd be +1 non-binding
--
Jeremy Thomerson
http://www.wickettraining.com
On Sat, Feb 28, 2009 at 3:33 PM, Brill Pappin
<br...@pappin.ca>
wrote:
I'm of the don't widen it camp anyway :)
So how do I go about gathering support for having the
DropDownChoice work
with the models the way everything else does?
- Brill
On 28-Feb-09, at 1:42 AM, Igor Vaynberg wrote:
yes, the choice was intentional. personally i do not care
if it
is <T>
all the way, some users complained so we widened it on the
choices
model, we cannot widen it on the main model.
-igor
On Fri, Feb 27, 2009 at 8:51 PM, Brill Pappin
<br...@pappin.ca> wrote:
I see... but this would i think because Bar "is a" Foo:
class Bar exends Foo {}
List<? extends Foo> list = ...
list.add(new Bar());
Anyway, what your saying is that the generics choice was
intentional?
- Brill
On 27-Feb-09, at 3:19 PM, Igor Vaynberg wrote:
list<? extends string> stings=...
strings.add("asd"); <== wont compile
-igor
On Fri, Feb 27, 2009 at 11:13 AM, Adriano dos Santos
Fernandes
<adrian...@gmail.com> wrote:
What do you mean with "read only" here?
Adriano
Igor Vaynberg escreveu:
<? extends Foo> collections are read only, it would be
too
inconvenient to make the model collection read only :)
-igor
On Thu, Feb 26, 2009 at 8:34 PM, Jeremy Thomerson
<jer...@wickettraining.com> wrote:
This is what I was commenting on last week on the list
(or earlier
this
week). One expects List<? extends Foo> while the other
expects
List<Foo>.
I'm not fully convinced yet that the "? extends" is the
better
option.
Either way, I think they should be the same.
--
Jeremy Thomerson
http://www.wickettraining.com
On Thu, Feb 26, 2009 at 8:27 PM, Brill Pappin <br...@pappin.ca
wrote:
Roughly what I'm doing is:
class TypeA{}
class TypeAModel extends LoadableDetachableModel<
List<TypeA>> {
public List<TypeA> load(){
... do the load ...
return ...
}
}
TypeAModel model = new TypeAModel();
DropDownChoice< TypeA> ddc = new
DropDownChoice<TypeA>("id", model
);
which gets complained about... in this case the
generic
def is
DropDownChoice<List<? extends T>>
I think the problem is that the generic def of the
class
should
actually
be
DropDownChoice<List<T>> because you are already
identifying the
type
when
you create a new instance.
Now... my generics are a bit hazy at this level,
because
I can
understand
why it was done that way... does anyone with more
generics
experience
know
what it should be? Is this a bug that needs filing?
- Brill
On 26-Feb-09, at 6:03 PM, Kaspar Fischer wrote:
On 26.02.2009, at 22:52, Brill Pappin wrote:
For some reason the DropDownChoice component doesn't
have the
same
generics as ListView and it will not accept a model
that
listview
will,
despite its saying that it will accept an IModel.
Is anyone else having that sort of trouble with
DropDownChoice?
- Brill
Can you give us more information on what exactly is
not
working
for
you?
DropDownChoice indeed does accept a model, see for
instance the
example
in
the class description at
http://wicket.apache.org/docs/1.4/org/apache/wicket/markup/html/form/DropDownChoice.html
This works for me.
Kaspar
--
<!-- HTML: -->
<select wicket:id="site">
<option>site 1</option>
<option>site 2</option>
</select>
<ul>
<li wicket:id="site2"><wicket:container
wicket:id="sitename"/></li>
</ul>
// Code
List SITES = Arrays.asList(new String[] {
"The Server Side", "Java Lobby", "Java.Net"
});
form.add(new DropDownChoice("site", SITES));
form.add(new ListView("site2", SITES)
{
@Override
protected void populateItem(ListItem item)
{
item.add(new Label("sitename", item.getModel()));
}
});
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-
unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
? extends
---------------------------------------------------------------------
To unsubscribe, e-mail: users-
unsubscr...@wicket.apache.org
For additional commands, e-mail: users-
h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-
unsubscr...@wicket.apache.org
For additional commands, e-mail: users-
h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
es, the choice
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-
h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
