[
https://issues.apache.org/jira/browse/WICKET-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569604#action_12569604
]
Matt Clark commented on WICKET-1312:
------------------------------------
Timo - Great patch. We have done something similar in our app
(http://www.nabble.com/Updating-distant-%28unrelated%29-components-via-Ajax-when-a-shared-model-changes-to13165777.html#a13165777),
although I like your approach better.
The one suggestion I would make is that you allow the event receivers to signal
that traversal should not go deeper. This became important in our use case
because you would have a parent add itself to the target, and then the child
would add itself. When the parent re-rendered the child was removed from the
page hierarchy, and by the time it got to render the child it was no longer
part of the page. If the parent knows that it is going to completely
re-compose its descendant hierarchy, then it can signal to the event
broadcaster to stop traversala t that point. I hope that was a clear enough
description.
> 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
>
>
> 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.
