Verbosity in Wicket is unnecessarily too much. Links below explaining my attempts to reduce the verbosity. May give some idea/clue
http://java.dzone.com/articles/faster-development-easywicket http://java.dzone.com/articles/event-mechanism-wicket ________________________________ From: tetsuo <ronald.tet...@gmail.com> To: "dev@wicket.apache.org" <dev@wicket.apache.org> Sent: Thursday, May 30, 2013 11:16 PM Subject: Re: Generified Component Fair enough. But: 1. you must explicitly declare a model for every component; 2. you must declare public, non-final accessor methods for every property (it won't work with direct attribute access); 3. it's black magic :) On Thu, May 30, 2013 at 4:47 PM, Martin Grigorov <mgrigo...@apache.org>wrote: > Hi, > > I'm not saying that I don't agree with you but most of the problems you > mention below are related to the models you use, PropertyModel and > CompoundPropertyModel, not to the generics of form components. > Check https://github.com/wicketstuff/core/wiki/LazyModel. You may see some > improvements in compilation help. > > > On Thu, May 30, 2013 at 10:37 PM, tetsuo <ronald.tet...@gmail.com> wrote: > > > -1000! > > > > This will be horrible! Even with the current API, most generics I have to > > declare in my code don't add anything to type safety. For example: > > > > add(new Form<Person>("form", new CompoundPropertyModel<Person>(new > > PropertyModel<Person>(this, "person"))) > > .add(new TextField<String>("name")) > > .add(new TextField<Integer>("age")) > > .add(new TextField<Double>("salary")) > > .add(new Button("save", new PropertyModel<Person>(this,"person")){ > > public void onSubmit() { > > repository.save((Person)getForm().getDefaultModelObject()); > > } > > }); > > > > In my experience, this kind of code is fairly common in Wicket > > applications. Every form component must be declared with a type, but none > > has *any* kind of type safety gain. > > > > - The property model uses reflection, so its type can't be verified by > the > > compiler (this.person could be anything, not just a Person). > > - Generics will guarantee that the form model will be of type Person, but > > since it's all declared inline, and the real model isn't verifiable, it > > just adds lots of verbosity without any real gain. > > - Most form components use the implicit model, that also uses reflection, > > and also can't verify the actual type of the underlying property, at > > compilation time. Even in runtime, *the type information is lost due > > erasure > > *, so it can't use it to do any additional verification. > > *- Worse, you can even declare the "name" TextField as <Integer> or > > <Double> (while maintaining the 'text' attribute as String), and since > > there is no type information at runtime, it doesn't matter. It won't even > > throw an exception (it will just work normally).* In this case, the type > > declaration is simply a lie. > > > > Just pain, no gain. In my code, I sometimes just add a @SuppressWarnings( > > "rawtypes") to the class, and remove all useless generic type > declarations. > > If everything will be required to declare them, I will have do it more > > frequently. > > > > That said, repeater components benefit greatly from generics. So do > custom > > models, validators, and converters. Or the rare cases that we explicitly > > declare the form component model. But forcing everything to be > > generic-typed will just make Wicket extremely verbose to use, with very > > little benefit. > > > > > > > > > > On Thu, May 30, 2013 at 4:00 AM, Martin Grigorov <mgrigo...@apache.org > > >wrote: > > > > > Hi, > > > > > > I just pushed some initial work for [1] and [2] in > > > branch generified-component-4930. > > > > > > So far it doesn't look nice. > > > > > > The added generics break somehow setMetaData/getMetaData methods - you > > can > > > see compilation errors in Component and Page classes. I think it is > > caused > > > by the anonymous instance of MetaDataKey ( new MetaDataKey<T>(type) {} > ). > > > > > > Also the visit*** methods do not compile at the moment, but even if we > > find > > > a way to fix their signature I think writing a visitor will become > quite > > > cumbersome. > > > At the moment we have IVisitor > > > and org.apache.wicket.util.iterator.AbstractHierarchyIterator which do > > the > > > same job. The Iterator API is supposed to be simpler to write for the > > > users. Maybe we can drop IVisitor ... ?! > > > > > > I'd like to ask for help with this task. It is supposed to be the > biggest > > > API break for Wicket 7.0. My current feeling is that the end result > won't > > > be very pleasant for the user-land code. > > > For example the application code will have to do something like: > > > > > > WebMarkupContainer<Void> wmc = new WebMarkupContainer<>("id") > > > > > > It is not that much but we have to decide whether we want it. > > > But first let's try to fix the compilation problems. > > > > > > > > > 1. https://issues.apache.org/jira/browse/WICKET-4930 (Add generics to > > > o.a.w.Component) > > > 2. > > > > > > > > > https://cwiki.apache.org/confluence/display/WICKET/Wicket+7.0+Roadmap#Wicket7.0Roadmap-Genericsfororg.apache.wicket.Component > > > > > >
