Hi > On 15. Jul 2025, at 14:59, Martijn Dashorst <martijn.dasho...@gmail.com> > wrote: > > However this would require adding a bunch of references, and much increased > memory usage. > > There are more issues, for example the `this` pointer is different (e.g. > not the component or behavior). There are certainly gotchas, but it is > worth exploring.
Looks like we independently came to quite similar scenarios. I hadn't thought of a builder pattern. Typically, I would use builders for immutable objects, not for stateful objects like Wicket components. A simple fluent style as Wicket already has it imho works well, except that currently the order of the fluent functions matters because e.g. if I call a fluent method inherited from Component, I can't afterwards use a Button fluent method anymore or assign the eventual component to a Button-typed variable. Does the memory usage matter a lot? Wrt. the this pointer: yeah, that sometimes comes up. However, most of the time I fill in method handles anyway. In those cases where I don't I typically assign the component to a variable that I can use inside the lambda instead of the this. I had also thought of passing in the component as an argument to the lambda. Joined the ASF channel ;) Do you think this is something limited to Wicket Bootstrap? Or would you just want to explore the concepts in that space before considering them for Wicket Core? -- Richard
