Since this is completely new code and there are no changes in Wicket's old/existing classes I'd recommend pushing these classes to Wicketstuff Core first. Once the new behaviors are polished and popular, move them over to wicket-core.
Being popular/used will give them some weight over the concerns that they will make the component tree heavier. My 2c. On Mon, Oct 27, 2025 at 12:21 PM Andrea Del Bene <[email protected]> wrote: > On Tue, Oct 14, 2025 at 12:37 PM Richard Eckart de Castilho < > [email protected]> > wrote: > > > Thanks for the proposal. > > > > > On 13. Oct 2025, at 17:16, Andrea Del Bene <[email protected]> > wrote: > > > > > > > > > https://github.com/apache/wicket/compare/master...bitstorm:wicket:lambda_spicing > > > > In your proposal, there are two classes "BehaviourBuilder" and > > "LambdaBehavior". The first always builds the latter. I would have > expected > > a "LambdaBehavior.builder()" factory method to create the builder and the > > builder being an internal class of the "LambdaBehavior". > > > > Right. Basically I like to keep LambdaBehavior available for those who want > to use directly in their code > > > > > > What I really like in your proposal is that all callbacks get the > > component as an argument, even "visibleWhen" and "enabledWhen". > > > > So an example using your approach: > > > > import static BehaviorBuilder; // let's discount this line > > > > component.add(BehaviorBuilder.newBuilder() > > .visibleWhen(this::isEasterEggFound) > > .enabledWhen(this::isEasterEggTriggered) > > .build(); > > > > In the current implementation of "LambdaBehavior" the "visibleWhen", > > "enabledWhen" and "onConfigure" methods seem to be mutually exclusive > > because they seem to override each other. If the idea is that the user > > would add a single "LambdaBehavior" to a component which covers multiple > > callbacks, then all of them should be usable. > > > > Yes, in this first implementation I did "visibleWhen", "enabledWhen" and > "onConfigure" methods are mutually exclusive. I think we should overcome > this limit working an the builder in order to remember the different > lambdas set by each method. In this way when we invoke build() we could > produce a single LambdaBehavior with the expected behavior. > > > > > > I (probably obviously) like the approach I had taken which uses static > > factory methods to create anonymous behaviours: > > > > import static LambdaBehavior.*; // let's discount this line > > > > component.add(visibleWhen(this::isEasterEggFound)) > > component.add(enabledWhen(this::isEasterEggTriggered)) > > > > Drawback on approach compared to yours is of course that it spams > > anonymous behaviour instances - I'm sure people would call that > inefficient > > (so far, I don't really mind). But on the positive side, I save calls to > > creating the builder and finalizing the builder which makes the code > quite > > a bit less verbose (and I appreciate concise and readable code). > > > > > > > https://github.com/inception-project/inception/blob/0d825f3f52909fed1d8699686d2f8536f03e4403/inception/inception-support/src/main/java/de/tudarmstadt/ukp/inception/support/lambda/LambdaBehavior.java#L167-L179 > > > > Maybe a hybrid/merger of the two approaches (builder + factory methods) > > would be viable. > > > > For sugar on top: > > > > I found it useful to also have "enabled/visibleWhenNot" and variations of > > the "when" methods that take a "IModel<Boolean>" instead of a supplier. > > > > I will try to rielaborate the code when I will have some spare time... > > Bye! >
