You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Martin Grigorov <mg...@apache.org> on 2015/04/27 14:13:30 UTC
OnAction behaviors
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
Re: OnAction behaviors
Posted by Martin Grigorov <mg...@apache.org>.
+1s: me, Emond, Dan Haywood
-1s: Andrew Geary, Sven
IMO there is not enough willingness to implement this feature in core.
I'll close the ticket.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Wed, Apr 29, 2015 at 3:40 PM, Martin Grigorov <mg...@apache.org>
wrote:
>
> On Wed, Apr 29, 2015 at 3:20 PM, Sven Meier <sv...@meiers.net> wrote:
>
>> 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();
>> }
>> }
>>
>
> Agreed! This is better!
>
>
>>
>> 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.
>>
>
> This is also what I said in my first comment in the ticket.
> But later I've started seeing sense it in. That's why I've asked for more
> opinions here.
>
>
>
>>
>> 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 <mg...@apache.org>
>>> 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 <sv...@meiers.net> 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 <sv...@meiers.net> 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 <
>>>>>>>> dan@haywood-associates.co.uk>
>>>>>>>> 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 <mg...@apache.org>
>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>
>
Re: OnAction behaviors
Posted by Martin Grigorov <mg...@apache.org>.
On Wed, Apr 29, 2015 at 3:20 PM, Sven Meier <sv...@meiers.net> wrote:
> 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();
> }
> }
>
Agreed! This is better!
>
> 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.
>
This is also what I said in my first comment in the ticket.
But later I've started seeing sense it in. That's why I've asked for more
opinions here.
>
> 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 <mg...@apache.org>
>> 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 <sv...@meiers.net> 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 <sv...@meiers.net> 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 <
>>>>>>> dan@haywood-associates.co.uk>
>>>>>>> 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 <mg...@apache.org>
>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>
Re: OnAction behaviors
Posted by Sven Meier <sv...@meiers.net>.
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 <mg...@apache.org>
> 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 <sv...@meiers.net> 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 <sv...@meiers.net> 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 <
>>>>>> dan@haywood-associates.co.uk>
>>>>>> 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 <mg...@apache.org>
>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
Re: OnAction behaviors
Posted by Martin Grigorov <mg...@apache.org>.
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 <mg...@apache.org>
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 <sv...@meiers.net> 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 <sv...@meiers.net> 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 <
>>>>> dan@haywood-associates.co.uk>
>>>>> 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 <mg...@apache.org>
>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>
>
Re: OnAction behaviors
Posted by Andrew Geery <an...@gmail.com>.
We also use an event/listener pattern with Wicket, but we use it in the
other direction: rather than sending events to its children, the button
bubbles an event up to a parent, usually the page, which handles it. Our
events are verbs like SaveEvent, DeleteEvent, EditEvent, AddEvent, etc. and
are generic so they can be used with different payloads (e.g., save person,
save order, save company, etc.). We also use the WicketStuff annotation
event dispatcher library to defined the handler methods with a simple
annotation [1].
To implement this, we simply extend the AjaxButton class where the onSubmit
method sends an event of a given type, using the model object of the
associated form as the payload. This can be expressed very concisely in
Java 8 where the event generator can be defined as
a java.util.function.Function or BiFunction (e.g., (form, target) -> new
SaveEvent<>(target, form.getModelObject())).
While I like the idea of buttons and links sending events, I don't really
see why this functionality should be in the core since it can be
accomplished by sub-classing existing components and I don't think every
component needs the functionality.
Andrew
[1]
https://github.com/wicketstuff/core/tree/master/jdk-1.7-parent/annotationeventdispatcher-parent
On Tue, Apr 28, 2015 at 7:56 AM, Martin Grigorov <mg...@apache.org>
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 <sv...@meiers.net> 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 <sv...@meiers.net> 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 <
> >>>> dan@haywood-associates.co.uk>
> >>>> 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 <mg...@apache.org>
> >>>>> 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
> >>>>>>
> >>>>>>
> >>>>>>
> >
>
Re: OnAction behaviors
Posted by Martin Grigorov <mg...@apache.org>.
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 <sv...@meiers.net> 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 <sv...@meiers.net> 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 <
>>>> dan@haywood-associates.co.uk>
>>>> 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 <mg...@apache.org>
>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>
Re: OnAction behaviors
Posted by Sven Meier <sv...@meiers.net>.
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 <sv...@meiers.net> 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 <
>>> dan@haywood-associates.co.uk>
>>> 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 <mg...@apache.org> 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
>>>>>
>>>>>
Re: OnAction behaviors
Posted by Martin Grigorov <mg...@apache.org>.
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 <sv...@meiers.net> 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 <
>> dan@haywood-associates.co.uk>
>> 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 <mg...@apache.org> 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
>>>>
>>>>
>
Re: OnAction behaviors
Posted by Sven Meier <sv...@meiers.net>.
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 <da...@haywood-associates.co.uk>
> 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 <mg...@apache.org> 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
>>>
Re: OnAction behaviors
Posted by Martin Grigorov <mg...@apache.org>.
Hi Dan,
On Mon, Apr 27, 2015 at 4:21 PM, Dan Haywood <da...@haywood-associates.co.uk>
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 <mg...@apache.org> 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
> >
>
Re: OnAction behaviors
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
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.
You could also perhaps submit events for the validation (allowing
subscribers to veto changes).
Cheers
Dan
On 27 April 2015 at 13:13, Martin Grigorov <mg...@apache.org> 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
>
Re: OnAction behaviors
Posted by Emond Papegaaij <em...@topicus.nl>.
Hi,
This sounds like a very useful feature. IMHO, the extra processing time is
insignificant. Even if you have several hundreds behaviors added to the
component, I doubt if it will take more than 1 or 2 ms to notify them all. We
already have beforeRender and afterRender methods, which are called way more
often and I've never seen any of those come up in a profiling session.
Best regards,
Emond
On Monday 27 April 2015 15:13:30 Martin Grigorov 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