On Jun 18, 2008, at 10:06 AM, 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 ;).
No, I'm not saying that there's anything wrong with components having
models -- just that components do a lot more than hold a model so
component/model coupling should be kept to a minimum.
So .. what do you have against using generic for models?
Nothing. It would be great if models could be made generic without
negatively impacting Wicket's API or turning it into an "expert only"
framework. But I'm not sure that's possible.
-Ryan
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
