[
https://issues.apache.org/jira/browse/WICKET-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604683#action_12604683
]
Timo Rantalaiho commented on WICKET-1312:
-----------------------------------------
Peter, thanks for the interesting idea, but surfing in the stack trace is
really too much magic at least for my taste! Also checking the method from
which the event got fired from (if I got that right) might complicate unit
testing.
> 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.5-M1
>
> 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.
