Hi Ryan, The problem is - I found out later - that we can't really generify models in a meaningful way without generifying components as well. At least, I haven't found a good way.
Do you have concrete suggestions or a proposal of how we could implement generics in a meaningful but non-obstrusive way? Eelco On 3/18/07, Ryan Holmes <[EMAIL PROTECTED]> wrote:
I think generic components are a mistake for several reasons. Not only is the snippet below ugly and redundant, it doesn't even save a cast if you're using a CompoundPropertyModel (which is the most common case in my app). Well, I guess you save one cast, but that's for the parent component's model, not for the form components themselves. At least for FormComponents, it's relatively obvious that a component's type == its model type. But what does it mean to specify the type for a Panel, Link, WebMarkupContainer, etc. when you're not even going to assign a model to the component (again, a fairly common case)? I think classes that make sense as generics don't have this problem -- they always hold, accept or return objects of their specified type. A lot of this boils down to the fact that a component's type parameter really has little to do with the component itself. It's for the underlying model (including validation/conversion to the model's object). Specifying the model's type in the component tightly couples the two together, which clashes with Wicket's concept of models as independent and dynamically resolvable objects (not to mention clashing with MVC in general). So, I completely agree with everything you said below and just wanted to throw out a "-1" for generic components hopefully before a final decision is made. -Ryan On Mar 6, 2007, at 9:57 PM, Eelco Hillenius wrote: > Hi, > > I think we went overboard applying generics in Wicket. > > Things like: > TextField<Integer> integerTextField = new TextField<Integer>(this, > "integerProperty", Integer.class); > > are just horrible imo. Sure, you can do: > > Integer i = integerTextField.getModelObject(); > > instead of: > > Integer i = (Integer)integerTextField.getModelObject(); > > but that's about the whole great benefit of generic components for the > price of about twice the verbosity. > > Also, calling getModelObject is the kind of convenience method that > grew upon us but that I personally never liked. It saves an ugly model > check, fine, but in general I think users should try to directly work > with models and their underlying objects instead. > > I can see the method come in handy in list views (on ListItem), though > then again, you know the model object would never be null there so > getModel().getObject() would work as well. > > Anyway, what I'd like us to consider is to de-generify components and > only keep it for models. For certain components (like ListView) we/ > users can decide to introduce it, but the general case would be to not > to. > > Thoughts? Screams? > > Eelco
