The decoupling doesn't have to be extremely painful. We could leave
support for the default slot in component, something like this:
class Component {
protected void setDefaultModel(IModel<?> model);
protected IModel<?> getDefaultModel();
}
class MyComponent<T> extends Component {
public void setModel(IModel<T> model); // note - no clashes, method
name is different
public IModel<T> getModel();
}
This would solve some problems with decoupling model, such as that
setModel has to do some magic (wrapping, etc). Also given the way
default model slot is currently implemented this has not bigger memory
footprint than not having the slot at all.
-Matej
On Sat, Jun 7, 2008 at 12:17 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
> I'm +1 for trying to decouple model from component, and if it takes longer
> then so be it.
>
> I'm pretty convinced that the problem is the 1-1 model-component coupling
> and that generics only pointed out this problem.
>
> Regards,
> Sebastiaan
>
> Igor Vaynberg wrote:
>>
>> so i tried to remove the generic type from component in
>> sandbox/ivaynberg/wicket-generics branch and ran into what i think is
>> a deal breaker for this design
>>
>> class component {
>> public void setmodel(imodel<?> model) {...}
>> public imodel<?> getmodel();
>> }
>>
>> that is all good until you want to have a generified subclass eg a
>> listitem:
>>
>> class listitem<t> extends component {
>> public imodel<t> getmodel() { return (imodel<t>)super.getmodel(); }
>> <== works like a charm
>> public void setmodel(imodel<t> model) {..} <== woops, compilation error
>>
>> Name clash: The method setModel(IModel<T>) of type ListItem<T> has the
>> same erasure as
>> setModel(IModel<?>) of type MarkupContainer but does not override it
>>
>> unfortunately the error makes sense and there is no way around it.
>> same goes for setmodelobject(). i think this makes this design variant
>> pretty useless. as long as we have the model coupled to component i
>> dont see a clean way of doing this :(
>>
>> class listitem<t> extends component {
>> public imodel<t> getmodel(..);
>> public void setmodel(imodel<?> model);
>> }
>>
>> looks half baked and broken by design
>>
>> 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.
>>
>> 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 )
>> 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"
>>
>> thoughts and ideas?
>>
>> -igor
>>
>> ---------------------------------------------------------------------
>> 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]
