+1 for finishing generics (no matter how ugly it gets), then
refactoring / removing the things that suck
Am 22.05.2008 um 11:37 schrieb Johan Compagner:
exactly Repeaters is very nice that the populateItem is generified..
I think
that is really handy..
And if the EditPage now wanted a specific type then you need now to
cast at
that place..
I thing that the example below is exactly the thing that generics
are pretty
good:
populateItem(ListItem<Person> item) {
add(new Link<Person>("edit", item.getModel()) {
public void onClick() {
setResponsePage(new EditPage(getModelObject()));
}
});
(and EditPage is by itself already generified to <Person>)
This is just a perfect thing that i say yes very nice you see
exactly what
the code should do
and cant say that this is really verbose..
johan
On Thu, May 22, 2008 at 11:28 AM, Martijn Dashorst <
[EMAIL PROTECTED]> wrote:
I often do the following:
populateItem(ListItem item) {
add(new Link("edit", item.getModel()) {
public void onClick() {
setResponsePage(new EditPage(getModelObject()));
}
});
}
So both are used often, but mostly to pass things around.
Martijn
On Thu, May 22, 2008 at 11:25 AM, Johan Compagner <[EMAIL PROTECTED]
>
wrote:
getModel() i agree, but getModelObject() is something that is used
the
most
if i have to guess.
Because in an onSubmit() of a form or a onClick of a Link what do
most of
you do?
onSubmit()
{
dao.save(getModelObject())
}
onClick()
{
dao.delete(getModelObject())
}
johan
On Thu, May 22, 2008 at 10:05 AM, Matej Knopp
<[EMAIL PROTECTED]>
wrote:
Although I'm not sure how many people call getModel/getModelObject
anyway. I think it's mostly about ListItems etc an i doubt anyone
would subclass it just because of getModel/getModelObject...
-Matej
On Thu, May 22, 2008 at 10:04 AM, Matej Knopp <[EMAIL PROTECTED]
>
wrote:
I would all be easier if getModel() and getModelObject() weren't
final. (I know there's a reason why they are, I'm not
questioning it).
Then in your component subclass you coud do IModel<Integer>
getModel()
{ return (IModel<Integer>)super.getModel() }, similiar with
getmodelobject so you wouldn't have casts all over places and it
would
be safer too).
-Matej
On Thu, May 22, 2008 at 9:39 AM, Johan Compagner <
[EMAIL PROTECTED]>
wrote:
It isnt all or nothing.. i never said that
I just say if you dont want Component but you do want IModel
then you will get a warning at getModel()
we as a framework shouldnt hide the warning at that call.
But i am also curious how many people get really the model back
from
a
component (not counting specific places like
repeaters.onpopuplate)
because i think most people do component.getModelObject() which
then
needs a
cast
But i like that extra helper method way more then having an extra
getUnsafeModel() method..
because thats explicit a developer has to really choose for it.
i think there are 3 options
1> keep it what we have now, tweak it with the feedback we get
from
1.4M2
2> drop it on Component only and have a class like you described
above
to do
this: IModel<String> model =
Unsafe.cast(component.getModel()); (its
still
a hack and a sense of false security but ok. if people really
want
this..)
3> drop it on Component and Model
i am +1 on 1
and -0 on 2 and 3
I still think it is not bad. and you can come around it really
easy
by
just
creating a few extra classes like
StringLabel
NumberLabel
StringTextField
NumberTextField
if you only have a few of those extra all your code is cleanup
johan
On Thu, May 22, 2008 at 9:12 AM, Joni Freeman
<[EMAIL PROTECTED]>
wrote:
Yeah, it could even be in its separate utility class:
interface IModel<T> {}
class Component {
private IModel<?> model;
public IModel<?> getModel() {
return model;
}
}
public class Unsafe {
public static <T> IModel<T> cast(IModel<?> model) {
return (IModel<T>) model;
}
}
class MyComp extends Component {
public MyComp() {
IModel<Integer> model = Unsafe.cast(getModel());
}
}
I'm merely pointing out that there exists a solution to do
unsafe
cast
without getting compiler warning. Just like normal casts are
handled.
I don't think Johan's all or nothing proposition is very
pragmatic
one.
Without generic IModel we do not get any API discoverability
and our
APIs continue to suck. For instance, how can API user know
what kind
of
model this needs: MyJuicyComponent(String id, IModel model).
At one
point we did this: MyJuicyComponent(String id, IModel/
*<Chocolate>*/
model) but this convention is far from optimal. To be sure, one
needs
to
browse the sources...
Joni
On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
Well, maybe it really is a hack that's too ugly. We might
have two
methods,
default getModel() that doesn't cast it and alternative
convenience
one that does.
-Matej
On Wed, May 21, 2008 at 10:10 PM, Matej Knopp <
[EMAIL PROTECTED]
wrote:
class Component {
private IModel<?> model;
public <T> IModel<T> getModel() {
return (IModel<T>) model;
}
}
I like this. Even with the possible class cast exception.
Because
without generics, it doesn't leave you no other option than to
cast
it
to your model, which isn't much better either, as you get the
same
result except that it looks uglier.
-Matej
On Wed, May 21, 2008 at 10:07 PM, Johan Compagner <
[EMAIL PROTECTED]> wrote:
no i am really against that falls <V> IModel<V> getModel()
method
that really abuses everything that generics stands for. For
such a
basic
thing.
this is really bad programming
If we drop it we also pretty much drop it from IModel or have
warnings
in
the user code.
But then drop it completely is better because then we have to
do a
cast and
you really think about that
Not having that fake assurance..
johan
On Wed, May 21, 2008 at 9:53 PM, Martijn Dashorst <
[EMAIL PROTECTED]> wrote:
Before we do a vote I want to make sure what our
alternatives
are.
I still like Joni's alternative. I don't think they are an
abomination, because the /potential/ class cast exception
you
get
is
the same as with current 1.3. But the benefit of documenting
the
model
parameters in DDC, LV, etc. is HUGE.
I really appreciate the time and effort that went into
implementing
the generification. But I also see what kind of mess this
brought
and
I really don't like the Component generification part.
Martijn
On Wed, May 21, 2008 at 9:24 PM, Igor Vaynberg <
[EMAIL PROTECTED]>
wrote:
ok so we pretty much have some core people wanting to back
out
the
generics support.
shall we start a vote? johan, gerolf and i have spent a
ridiculous
amount of time trying to generify the codebase and remove
all
the
shitty warnings. if there is even a slight chance of this
getting
backed out i do not want to spend any more time on this
until
the
issue is resolved.
also we should halt m2 until this is resolved.
personally i do not mind backing out generics, they turned
out
to
be
quiet a disappointment for me as well, but my feelings
about
this
are
not strong.
we can still use generics such as setresponsepage(class<?
extends
page>) to gain bits of typesafety here and there, but if we
remove
them from component we obviously have to remove them from
imodel.
so lets start a vote with a parallel discussion thread just
for
this.
-igor
On Wed, May 21, 2008 at 8:19 AM, Martijn Dashorst
<[EMAIL PROTECTED]> wrote:
On Wed, May 21, 2008 at 5:05 PM, Johan Compagner <
[EMAIL PROTECTED]>
wrote:
Generics is type safety
I didn't say generics isn't type safety. But APPLYING
generics
for
the
Wicket framework API *ISN'T* its primary goal. API clarity
*IS*.
Less
questions on the mailing list regarding DDC, ListView,
etc.
is
the
main goal for applying generics in Wicket.
I am against this abuse big time -1000 from me
I'm -1000000000000000^1000000000000 for abusing my eyes
and
brain
in
the way it currently is implemented in Wicket. It is
completely
and
utterly unusable for beginners. There is no way this is
going
to
make
the number of questions on the mailinglist less (other
than
by
scaring
away anyone that wants to actually use the framework)
Martijn
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/
1.3.3
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: users-
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
