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:
ryan@...]
> Gesendet: Di 20.03.2007 07:58
> An:
wicket-dev@...
> 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
>
>
>