I can really see the need for using generics for models, especially if
you do some generic stuff for a detachable model, something like below.
Another thing which I havent that through at all but it would also be
very handy if we somehow could make using propertymodels type
safe/refractorable. Eg something like this new PropertyModel(myObj,
MyObj.Property), since it will be refactorable.. Instead of doing it
with strings, but it might just not be possible, can't see how..
package zeuzgroup.application.models;
import org.apache.wicket.injection.web.InjectorHolder;
import org.apache.wicket.model.LoadableDetachableModel;
import org.apache.wicket.spring.injection.annot.SpringBean;
import zeuzgroup.core.BaseEntity;
import zeuzgroup.core.provider.IDBDao;
public class BaseEntityDetachableModel <E extends BaseEntity> extends
LoadableDetachableModel {
@SpringBean(name = "dBDao")
protected IDBDao dBDao;
private Long id;
private Class<E> clazz;
public BaseEntityDetachableModel() {
InjectorHolder.getInjector().inject(this);
}
public BaseEntityDetachableModel(E baseEntity) {
this();
this.id = baseEntity.getId();
this.clazz = (Class<E>) baseEntity.getClass();
}
public void setBaseEntityDetachableModel(E baseEntity) {
this.id = baseEntity.getId();
this.clazz =(Class<E>) baseEntity.getClass();
}
@Override
protected E load() {
if(clazz!=null)
{
return dBDao.findEntity(id, clazz);
}
else{
return null;
}
}
}
Sven Meier wrote:
IMHO we shouldn't blame everything on the fact that each component has
a model. I'm working with Wicket for three years now and the whole
component <-> model relation worked out nicely most of the time.
I won't say that we shouldn't try to improve the matter ;).
So .. what do you have against using generic for models?
Sven
Ryan Holmes schrieb:
I'm not sure how useful this is, but I think you should seriously
consider dropping generics altogether at this point. Obviously, you
should use them internally wherever it makes sense but keep them out
of the API. Here are my reasons, as obvious and simple-minded as they
may be:
1) Casting model objects is not a major pain point. The users who are
most bothered by it are motivated more by philosophical
considerations and personal preference than by actual technical
impediments. iow, I've never heard anyone complain that "man, I like
Wicket but all that casting is really slowing me down and breaking my
application".
2) A generified Wicket API will cause actual technical impediments
and a potentially major reduction in productivity. So, in this case,
I think the "solution" for non type-safe models presents worse
problems than the problem it was meant to solve.
3) As you're all well aware, the implementation of generics in Java
has severe limitations and complications. Generics are still very
useful but, due to the implementation, they either don't work or tend
to spiral out of control in complex situations.
4) I think it's inconsistent with the design of Component for it to
take a model type parameter at all (even if generics were implemented
cleanly in Java). Generics work well for classes whose primary
purpose is to hold other objects (like a collection or "Pair") or
that represent highly cohesive functionality (like the Comparable
interface). Component does not fall into either of these categories.
In fact, the model of a component should be entirely optional and
freely assignable without having to worry about what type of
component to which it belongs (within certain limitations, of
course). In short, I think the Component type parameter makes the
relationship between a component and its model too rigid / inflexible
/ brittle.
Another thing I'd like to point out is that I don't think most users
know what they're asking for when they say they really want a
generified Wicket. I don't think they understand the design
implications and how much it will complicate the API and I think they
would change their minds if they did. Java programmers tend to always
gravitate toward more type safety because we know how much value
static type checking provides. But, inevitably, an obsession with
type safety leads to a loss of flexibility and an increase in
complexity. At least that's been my experience.
I'm sure most of this falls into the category of "stating the
obvious", but hopefully my somewhat blunt opinion adds something to
the discussion...
-Ryan Holmes
On Jun 4, 2008, at 4:53 AM, Matej Knopp wrote:
The generics discussion seems to have no end. But one thing seems to
be quite apparent to me. Most people using Wicket 1.4 on real project
aren't really happy with it. But everyone agrees that there are
benefits too. So say we went the way of generics for models only, i.e.
Component getModel would return IModel<?> and getModelObject would
return Object. We would also leave get/setModel and get/setModelObject
non final (with a big fat javadoc explaining why) so that we would
allow generified subclasses where it makes sense (ListView/ListItem).
What potential caveats would this approach have? (Except maybe for the
obvious less strict type checking)
-Matej
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
