[jira] Issue Comment Edited: (WICKET-1312) Generic inter-component event mechanism

["Sven Ludwig (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WICKET-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12917573#action_12917573 ] 

Sven Ludwig edited comment on WICKET-1312 at 10/4/10 8:31 AM:
--------------------------------------------------------------

The Interfaces look promising. I have two points for consideration.

The first point is on the sending side. The sink along with the Broadcast enum value are arguments of the method send, i.e. the sender (a Component, or a Behavior, or some delegate code being responsible for the sending etc.) of an event needs to know into what scope the event is to be broadcasted, and how. Of course, there is for example the combination getPage() and BREADTH, which would be like a truly decoupled solution to broadcast an Event, because the sender knows no one Component in particular, it only knows that it sends the event to any interested receiver within the current Page. But it may get dogy when the sender needs to resolve or even know a particular Component that should be the sink. But I do like the flexibility here.

The second point is on the receiving side. How does a receiver decide in onEvent whether to do something or not? The implementation of the onEvent method might be able to define the type of event payload that it can process simply within the method signature - if so, onEvent would never be called with a mismatching type of payload. However, if this is not possible, or not supported by the core, or as soon as there are two types of event payloads to be processed in different ways by one onEvent implementation... then the onEvent implementation would have to distinguish between the payloads of received events. How would it do that? The payload may be of a general kind with an enumeration representing its functional meaning... but who wants an enumeration with all functionally possible event meanings... so it would probably be a specific payload type... and this type would have to be checked instanceof-fashion within onEvent. This approach is quite flexible. But in cases where there are only a few interested components among many event-processing components, potentially all of the components would do instanceof-checks of the payload type, which basically might take some processing power away.
As a performance-optimizing solution for such cases, an additional approach could be offered in which the interested receivers would be registered as event-listeners for events with a specific payload type. Of course there would have to be a registry mechanism with a sensible scoping. The core broadcasting mechanism would then, during the broadcasting of an event, only call onEvent on the registered listeners within the relevant scope. This alternative may be implemented under a dedicated Broadcast enum value LISTENERS_ONLY.


      was (Author: sludwig):
    The Interfaces look promising. I have two points for the developers consideration.

The first point is on the sending side. The sink along with the Broadcast enum value are arguments of the method send, i.e. the sender (a Component, or a Behavior, or some delegate code being responsible for the sending etc.) of an event needs to know into what scope the event is to be broadcasted, and how. Of course, there is for example the combination getPage() and BREADTH, which would be like a truly decoupled solution to broadcast an Event, because the sender knows no one Component in particular, it only knows that it sends the event to any interested receiver within the current Page. But it may get dogy when the sender needs to resolve or even know a particular Component that should be the sink. But I do like the flexibility here.

The second point is on the receiving side. How does a receiver decide in onEvent whether to do something or not? The implementation of the onEvent method might be able to define the type of event payload that it can process - if so, onEvent would never be called with a mismatching type of payload. However, if this is not possible, or not supported by the core, or as soon as there are two types of event payloads to be processed in different ways by one onEvent implementation... then the onEvent implementation would have to distinguish between the payloads of received events. How would it do that? The payload may be of a general kind with an enumeration representing its functional identity... but who wants an enumeration with all functionally possible events... so it would probably be a specific payload type... and this type would have to be checked instanceof-fashion within onEvent. This is quite flexible, but in cases where there are only a few interested components among many event-processing components, potentially all of the components would do instanceof-checks of the payload type, which basically might take some processing power away.
As a performance-optimizing solution for such cases, an additional approach could be offered in which the interested receivers would be registered as event-listeners for events with a specific payload type. The core broadcasting mechanism would then only call onEvent on the registered listeners during the broadcasting of an event. This alternative may be implemented under a dedicated Broadcast enum value LISTENERS_ONLY.

  
> Generic inter-component event mechanism
> ---------------------------------------
>
>                 Key: WICKET-1312
>                 URL: https://issues.apache.org/jira/browse/WICKET-1312
>             Project: Wicket
>          Issue Type: New Feature
>          Components: wicket-extensions
>    Affects Versions: 1.3.0-final
>            Reporter: Timo Rantalaiho
>            Assignee: Igor Vaynberg
>             Fix For: 1.5-M2.1
>
>         Attachments: event-handler-with-testcase.zip, Generic_EventBroadcaster.patch, Generic_EventBroadcaster_glued_in_Component.patch
>
>
> The attached patch provides a generic mechanism for transmitting inter-component events within a page. This has grown primarily from the need to repaint all relevant ajax components after an event, but can be used also in non-ajax environments such as after normal form submits.
> The basic idea is to fire an IVisitor on the page of the component sending an event, giving as an argument an event-specific listener interface that must be implemented by the components willing to receive the events. They can then do whatever they need such as add themselves to the AjaxRequestTarget that can be supplied in the event.
> Sometimes the basic Wicket mechanisms such as sharing a model are not enough; particularly repainting all relevant components in Ajax events gets tedious if the components are far away from each other in a complex DOM tree.
> The benefits of this approach are
> - loose coupling between the sending and receiving end
> - however, because of strong static typing it's easy enough to find with an IDE from where the events are broadcasted and where they are received
> - good testability (EventBroadcaster can be mocked on the sending end, and event handlers tested directly on the receiving end, possibly with mock events)
> - no need the keep references to Component instances or their paths (which could have been problematic on repeaters)
> (This is not a real observer or listener pattern implementation because the components cannot register and unregister themselves dynamically, but "registering" is handled statically on a class basis by implementing the relevant event receiver interface.)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.