On Thu, Jun 19, 2008 at 8:57 AM, Ryan Holmes <[EMAIL PROTECTED]> wrote: > 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.
i think it is possible. not pretty, but possible. rename set/getmodel to set/getDefaultModel - these work with imodel<?> this expresses that each component holds an instance of model and doesnt care about its type - which is true for most components components that actually do use the model, eg dropdownchoice can implement set/getmodel that work with type <T> like i said, not pretty, but its a part-way solution. in 1.5 we will most likely remove the default model altogether if we find a good way of doing that. -igor > > -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 >>> >>> >> > >
