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".
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.
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.
Cheers,
-- Richard
