this is actually a perfect example where generifying Component broke down in 1.4m2. dataview does not use its model, it uses the dataprovider which it stores as a field. so right now you can just say new DataView<Foo> and it will expect IDataProvider<Foo> and you are free to attach any type of model to the dataview you want.
in 1.4m2 if we reused the same type declaration for dataprovider and dataview then you would be forced to only use imodel<foo> for the dataview which is a completely arbitrary restriction. to fix the above we would have to allow two type declarations, one for model and one for dataprovider. so now you have to do new DataView<Void,Foo> which is very noisy not to mention you have to remember which one is for the model and which one is for the dataprovider. in m3 we do not have this problem... -igor On Wed, Jul 16, 2008 at 11:34 AM, JulianS <[EMAIL PROTECTED]> wrote: > > I converted our project to 1.4 as an experiment. It's quite large (257 source > files). It was a bit tedious changing xxxModel to xxDefaultModel, etc, but > it wasn't too bad. I haven't fixed all the warnings though. > > I think the design will benefit us and the conversion will be worth it. We > use this pattern a lot: data provider + data panel + data view. Generifying > the models these classes deal with reduces confusion, potential runtime > errors and code size (the latter because you can get rid of casts and you > can move some code to superclasses). > > Thanks to the Wicket team yet again! > Julian > -- > View this message in context: > http://www.nabble.com/generics-tp18083910p18493875.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > 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]
