In our applications, most components benefit from being generic. Even a 
Markupcontainer with custom components is used generic.
 
Stefan Lindner

________________________________

Von: Ryan Holmes [mailto:[EMAIL PROTECTED]
Gesendet: Di 20.03.2007 08:56
An: [email protected]
Betreff: Re: generics in Wicket




On Mar 20, 2007, at 12:35 AM, Stefan Lindner wrote:

> So the component developert must be very disciplined because the 
> local variable "model" ist not generic. You can assign whatever 
> IModel you want to the local "model". And the "return this.model" 
> line will cause a warning.
The "return this.model" line is in the framework. The 2.0 code base 
is full of raw references to components which also cause warnings/
unchecked casts, so I don't think that's an issue. No argument on 
your bigger point that what I wrote below doesn't enforce type safety 
inside the component.
>
> In most cases it makes sense to have Generic components.
But that's what I'm having a hard time with (and maybe it's just 
because I haven't used 2.0) -- it seems like the majority of 
component instances don't benefit from being generic. You obviously 
use and like generic components quite a bit, so maybe you can give me 
some perspective. These are essentially the same questions I asked 
Philip:

When you have a form with a CompoundPropertyModel, do you still 
declare the type of the form components and, if so, why?

What about MarkupContainer components that you don't specify a model 
for?

-Ryan


>
> Stefan Lindner
>
> ________________________________
>
> Von: Ryan Holmes [mailto:[EMAIL PROTECTED]
> Gesendet: Di 20.03.2007 07:58
> An: [email protected]
> Betreff: Re: generics in Wicket
>
>
>
>
> On Mar 19, 2007, at 12:58 AM, Eelco Hillenius wrote:
>>
>> Do you have an idea that works without having to generify Component?
>>
>
> Not sure if you would put this in the "idea that works" category, but
> I was thinking of something like this:
>
> public class Component {
>         private IModel model;
>
>         public <T> Component(final String id, final IModel<T> model) {
>                 this.model = model;
>         }
>
>         public <T> IModel<T> getModel() {
>                 return this.model;
>         }
>
>         public <T> void setModel(IModel<T> model) {
>                 this.model = model;
>         }
> }
>
> This accommodates generic models but doesn't enforce type consistency
> between getModel and setModel. In practice, the types would usually
> be inferred:
>
> IModel<Integer> model = component.getModel();
>
> so it's easy to use and does eliminate casting, but get/set model
> inconsistency would only be caught at runtime (unless you use the
> full generic method syntax with a type parameter)
>
> I don't know -- it doesn't really buy you much. This doesn't work:
>
> Integer i = component.getModel().getObject();
>
> I also played around with the idea of a generic "ModelHolder" object
> inside of Component so at least getModel() and setModel() would use
> the same type parameter, but again the get/set model methods on
> Component itself can't pick that type up.
>
> <sigh> Oh well, maybe it's just taking me longer to come to the same
> conclusion you did.
>
> -Ryan
>
>
>



Reply via email to