Hi, I see your point.
We could have both: label1.add(Behavior.onTag(t->t.put(key, label1.getId())); label1.add(Behavior.onTag((c, t)->t.put(key, c.getId())); Both the Eclipse and JDK compiler accept these. The component should come as first argument as in Behavior#onComponentTag(Component, ComponentTag) though. I'd like to preserve the first one because it's syntactically shorter. Have fun Sven
On 02.12.2016 17:58, Martijn Dashorst wrote:
But it would add another reference to the component, increasing the footprint. It also enables you to 'bind' to another (unintended) component that's available in the scope. Label label1 = new Label(...); ... Label label4 = new Label(...); label1.add(Behavior.onTag(t->t.put(key, label4.getId())); When supplying the component as a second parameter in the onTag, you direct the developer to know what the intention is: label1.add(Behavior.onTag(t,c -> t.put(key, c.getId())); Martijn On Fri, Nov 25, 2016 at 9:27 PM, Sven Meier <s...@meiers.net> wrote:Hi, the behavior is added to a single component only and readily available anyway in scope: component.add(onTag(tag -> tag.put(key, component.getId())); What do we gain when the same component is given as argument? component.add(onTag(component, tag -> tag.put(key, component.getId()))); Note that the first component has a better type, the argument would just be a Component: foo.add(onTag(tag -> tag.put(key, foo.getBar()))); Regards Sven On 25.11.2016 20:51, Martin Grigorov wrote:Hi, At Martijn's slides from ApacheCon [1] I've noticed that critiques he mention is that org.apache.wicket.behavior.Behavior#onTag() uses SerializableConsumer<ComponentTag> and ignores the Component parameter. I agree that having the component would be handy! Any good reasons why it should be like this ? 1. http://events.linuxfoundation.org/sites/events/files/slides/Whats%20up%20with%20Wicket%208%20and%20Java%208.pdf Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov
