i dont think listitem#setmodel is restricted in your example.to T in ListItem<T>
> public <T> ListItem setModel(IModel<T> model)
the first <T> hides the T of ListItem<T> so you might as well have
said <X> setModel(IModel<X> model)
-igor
On Sat, Jun 7, 2008 at 4:48 AM, Timo Rantalaiho <[EMAIL PROTECTED]> wrote:
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
