Hi, I don't see any reason for having a class that only aliases methods in other classes. So here's +1 for 'v'.
The onUpdate/onSubmit/onChange methods all suffer from the same problem: you either need 2 lambda's or you provide an incomplete API. If we only provide a method with 1 lambda you cannot add on onError handler when needed without rewriting the entire portion of code. If we provide both, you get really ugly code with 2 lambda's. So +1 to remove these as well. onTag and onAttribute seem a misfit for lambda's because they provide low-level access using a high-level API. Personally, I only use those when performance or memory usage are an issue. Using lambda's defeats the purpose. So +1 to remove these as well. Personally, I only see good use for a few of the methods: onTimer, onClientInfo, onEvent, onNewWindow, onSelfUpdate I'm not sure if lambda's add that much, but they don't hurt either, so no vote for these :) Best regards, Emond On Tue, Feb 28, 2017 at 7:16 PM, Sven Meier <[email protected]> wrote: > Hi all, > > currently we have 15 behavior factory methods in > org.apache.wicket.lambda.Lambdas, all forwarding to the actual > implementations in different behavior classes. > 4 of these methods require two lambda parameters (success- and > error-handler), something which has already been criticized as being unclear > and hard to name well. > > This is a vote on what to do with these factory methods in Wicket 8.x: > > a) remove them all > > b) remove the 4 'complicated' ones (with more than one lambda argument) > > c) keep them all as they are > > v) remove Lambdas class but keep factory methods in the behavior classes > > w) remove factory methods from behavior classes but keep them in Lambdas > class. > > We'll need at least 3 binding votes to go from here, let's see what we can > agree on. > > Have fun > Sven >
