[
https://issues.apache.org/jira/browse/WICKET-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12917573#action_12917573
]
Sven Ludwig commented on WICKET-1312:
-------------------------------------
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.
