Hi, These methods are factories for the trivial use cases where nothing else needs to be overridden but the action method (methods, when there is onError()). They do help to reduce the verbosity! There are plenty of those cases. You can see many usages in wicket-examples. I have used such methods from wicketstuff-scala in one of my projects in the past and I use similar ones in a project with Kotlin now.
A builder that provides methods like onConfigure(), onComponentTag(), onDetach(), ... would look really strange! Who will use it instead of just creating a (inner) class ?! But if those factory methods confuse core developers then they will be even more confusing to normal users :-/ 0 from me. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Tue, Feb 7, 2017 at 5:07 PM, Martijn Dashorst <[email protected] > wrote: > All, > > I want to remove all component factory methods that are added for lambda's. > > My reasoning is that: > - removing them in 8.x (x > 0) is impossible > - adding them in 8.x (x > 0) is trivial > - we currently don't have a way to know what good idioms are > - having these factories push (new) developers to use the wrong idiom > - factory methods don't allow for additional overriding, thus a > combinatorial explosion of API > - I tend to think that builders are better suited as component factories > > Because it is trivial to re-introduce these factories or their > replacements at a later time, I propose to remove them now and figure > out in our actual applications what works, and what doesn't. I also > think that just doing the conversion from W7 to W8 isn't enough to > figure this out. > > Example 1: > > Button.java has two factory methods: > > Button#onSubmit(String, SerializableConsumer<Button>), and > Button#onSubmit(String, SerializableConsumer<Button>, > SerializableConsumer<Button>) > > It is not possible to see without resorting to parameter naming, > hovering etc to see which functionality is bound by which parameter. I > find the naming confusing: onSubmit and onSubmit. > > Example 2: > > Behavior.java has two factory methods: > > Behavior onTag(SerializableBiConsumer<Component, ComponentTag>) > Behavior onAttribute(String name, > SerializableFunction<String, CharSequence> onAttribute) > > These achieve basically the same functionality, but other life cycle > events of Behavior don't have factory methods. NOR should they. > > Example 3: > > Lambdas.java has many factory methods, most of which are better > implemented by just using an anonymous inner class. For example, > Lambdas.link: often times you need to override onconfigure or > oncomponenttag as well as onclick. > > Martijn >
