Hi Igor and others,
Great that you tried that out in practice!
On Sat, 07 Jun 2008, Igor Vaynberg wrote:
> class component {
> public void setmodel(imodel<?> model) {...}
> public imodel<?> getmodel();
> }
I was earlier trying out this variant:
public class Component {
public <T> Component setModel(final IModel<T> model) { ... }
public IModel<?> getModel() { ... }
public Object getModelObject() { ... }
public <T> Component setModelObject(final T object) { ... }
}
and as far as I can tell, this does not inhibit the same
problem with generified subclasses. E.g. this works
public class ListItem<T> extends WebMarkupContainer {
@SuppressWarnings({"unchecked"})
@Override
public IModel<T> getModel()
{
return (IModel<T>) super.getModel();
}
@Override
public <T> ListItem setModel(IModel<T> model)
{
return (ListItem) super.setModel(model);
}
@SuppressWarnings({"unchecked"})
@Override
public T getModelObject()
{
return (T) super.getModelObject();
}
@Override
public <T> Component setModelObject(T object)
{
return super.setModelObject(object);
}
...
}
The unchecked cast warning when casting Object to T in
getModelObject() is a bummer, but then again I didn't
even think that getModelObject() would be overriden in
the generified subclasses (I don't consider needing to do
Foo foo = (Foo) getModelObject() a problem). The same
goes for getModel().
> i would almost reconsider 1.4 and its scope and opt to include a model
> decoupling (however and if that is possible) refactor in it. otherwise
> i fear we will break the whole generics model again in 1.5 and users
> will have to relearn how to use them with wicket.
Model decoupling would mean removing the default IModel of
Component, that was discussed this week, right?
It seems like a great idea [1] on the longer run, but as far as
I understand, the idea was to
- drop 1.3 support when 1.4 comes out
- offer 1.4 as a drop-in replacement (except for Java 5
requirement) for 1.3 users
- leave API breaks for 1.5
...and I don't see how the decoupling could happen without
a big API break.
So then it would effectively mean continuing Wicket 1.3 (and
Java 1.4) support for longer?
> so as far as i can see, and this is only my opinion, our options are:
>
> continue 1.4 as it is now with fully typed components
> remove component type but make the api ugly ( i will let matej explain )
Matej, please explain :)
> attempt to fix 1.4 by decoupling model from component - 1.4 takes a
> lot longer and is not a simple "drop-in/upgrade/whatever"
Yet another option would be to address this only in 1.5, and
drop Component and IModel generics from 1.4 altogether.
Best wishes,
Timo
[1] The Component class has a lot of responsibilities, so
removing any of them, such as the default model handling, is
a step to the right direction.
--
Timo Rantalaiho
Reaktor Innovations Oy <URL: http://www.ri.fi/ >
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
