On Fri, May 31, 2013 at 4:24 PM, tetsuo <[email protected]> wrote:
> Black magic, or code generation? hard choice... :) > I think I'll try the black magic, let's see how it goes :) > I personally prefer writing the boilerplate of custom Model per field. It is a boring work but it gives me: * type safety * the fastest read/write access possible * easier debugging (who knows - maybe I've spent less time to write such models than you've spent to debug your issues with property model after refactoring) > > > On Thu, May 30, 2013 at 8:16 PM, Igor Vaynberg <[email protected] > >wrote: > > > On Thu, May 30, 2013 at 12:37 PM, tetsuo <[email protected]> > 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: > > > > while i am also not a fan of having component generified i do believe > > the example below is a bit contrived. > > > > first, i hope most people do not use PropertyModels because they are > > not compile-time-safe. there are plenty of project that implement > > compile-time-safe models, personally i prefer > > https://github.com/42Lines/metagen to using proxy-based solutions. > > > > further, i hope even less people use compound property models. they > > are even more unsafe then property models and make your code even more > > fragile. i would hate to refactor code that uses CPMs. > > > > > 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. > > > > but how often do you declare a form component without adding any > > validators to it? the generic type of component also makes sure you > > add the correct validator. for example it wont let you add a validator > > that expects strings to a component that produces integers. > > > > also, not sure why you are replicating the model in Button. first, the > > Button uses its model to fill its label; secondly, in real code the > > model would be in a final var or field that things like onsubmit can > > access easily. > > > > -igor > > > > > > > > > > - 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 <[email protected] > > >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 > > >> > > >
