Hi, +1 to keep the factory methods.
We updated our current project (~100k lines) to 8.0.0-M3 and thought the factories were very handy. They cover a lot of simple components like AjaxLinks which are a lot shorter and more readable afterwards. Best regards, Martin On Tuesday, February 7, 2017 11:40:34 PM CET Martin Grigorov wrote: > 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
