[
https://issues.apache.org/jira/browse/WICKET-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604674#action_12604674
]
James Carman commented on WICKET-1312:
--------------------------------------
Are we going to introduce this stuff in 1.4? I thought 1.4 was all about
generification?
> 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-M3
>
> 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.
