[ https://issues.apache.org/jira/browse/WICKET-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12900042#action_12900042 ]
Hudson commented on WICKET-1312: -------------------------------- Integrated in Apache Wicket 1.5.x #247 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/247/]) initial inter-component event system implementation Issue: WICKET-1312 > 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 > > 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.