If I understand you correctly, you're proposing the following:
Button {
publiv void onSubmit() {
send(this, Broadcast.EXACT, new SubmitPayload());
}
public static class SubmitPayload {
}
}
Correct?
IMHO this would be easier then:
Button {
publiv void onSubmit() {
for (ClickListener listener : getBehaviors(ClickListener.class)) {
listener.onSubmit();
}
}
public static interface ClickListener {
public void onSubmit();
}
}
But I don't like either of these solution. I agree with Andrew that this
does not belong into core, people can build this on top of wicket.
Perhaps you have something different in mind?
Regards
Sven
On 28.04.2015 22:30, Martin Grigorov wrote:
Hi Sven,
Maybe I didn't understand your idea with the interfaces.
wicket-core components should instantiate the payload and broadcast it.
How something implemented by the application will be instantiated by Wicket?
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Tue, Apr 28, 2015 at 2:56 PM, Martin Grigorov <[email protected]>
wrote:
Hi Sven,
The only problem I see with the interfaces approach is that it won't be
easy to extend them with extra functionality in a minor release if this is
ever needed.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Tue, Apr 28, 2015 at 12:47 PM, Sven Meier <[email protected]> wrote:
Hi Martin,
why not just define interfaces in Components, and allow behaviors to
implement these?
Not that I'm convinced of the usefulness of this feature :P.
Regards
Sven
On 28.04.2015 11:23, Martin Grigorov wrote:
Hi Sven,
I imagine them as inner static classes in AbstractLink, Button and Form
classes.
AjaxRequestTarget will be an optional property for the event payload.
I.e.
AjaxButton will set it, Button will leave it null.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Tue, Apr 28, 2015 at 12:11 PM, Sven Meier <[email protected]> wrote:
Hi,
how (where) will these events (=payloads?) be defined?
Sven
On 28.04.2015 08:29, Martin Grigorov wrote:
Hi Dan,
On Mon, Apr 27, 2015 at 4:21 PM, Dan Haywood <
[email protected]>
wrote:
Sounds a bit similar to Apache Isis' support for domain events
(albeit
at a
higher level of abstraction).
we've found that feature very useful, so I would imagine there would
be
benefits from implementing this lower more general support in Wicket.
Thanks for sharing your experience!
You could also perhaps submit events for the validation (allowing
subscribers to veto changes).
IMO there is no need to do this for validation.
Currently when an IValidator is added to a FormComponent it is
automatically wrapped in a Behavior [1].
So Wicket will use the typesafer IValidator#validate(IValidatable)
instead
of Behavior#onEvent(IEvent)
1.
https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/markup/html/form/FormComponent.java#L515
Cheers
Dan
On 27 April 2015 at 13:13, Martin Grigorov <[email protected]>
wrote:
Hi,
https://issues.apache.org/jira/browse/WICKET-5884 suggest an
interesting
feature:
All links/buttons/forms to broadcast Wicket events to their Behaviors
about
the event.
I.e. a Link/Button will tell all its Behaviors that it has been
clicked,
a
Form will tell that it has been submitted.
The broadcast would be with type EXACT so only the current component
and
its behaviors will be notified via #onEvent().
This way the application developer can reuse functionality that
should
be
executed for several links/submitters.
While I see how this could be useful for some applications I also see
that
it will add to the processing time for all applications no matter
whether
they use the feature or not.
Also I guess some user will ask for OnBeforeButtonSubmitEvent +
OnAfterButtonSubmitEvent (same for Link and Form) so the extra
processing
time be doubled.
What do you think about the feature?
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
