[
https://issues.apache.org/jira/browse/WICKET-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timo Rantalaiho updated WICKET-1312:
------------------------------------
Attachment: Generic_EventBroadcaster_glued_in_Component.patch
This patch (Generic_EventBroadcaster_glued_in_Component.patch) adds the method
public void broadcast(Class receiverType, Event event) directly to Component,
along the lines suggested by Pekka Enberg (thanks!). Thus the event package is
also moved from wicket-extensions to main wicket module.
EventBroadcaster is now also made a non-enforced / pluggable singleton. There
must be an easy way to intercept and inspect the event broadcasting in unit
tests. This solution provides it in a very straight forward, if not eloquent,
way.
Against revision 628453 (Sun Feb 17 2008).
> 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
> Fix For: 1.4-M1
>
> Attachments: 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.
