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
