[
https://issues.apache.org/jira/browse/WICKET-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631687#action_12631687
]
Stefan Fussenegger commented on WICKET-1312:
--------------------------------------------
Hi Timo, thanks for your comments.
1) You're right. But I feel that differentiating between events should be up to
the framework users not the framework itself. For instance: you propose an
IntegerChangeEvent, I use such things as NewCommentEvents. These are two
completely different layers of abstractions that heavily depend on what you try
to do with those events in your application. I only want to add components if
another component receives an ajax call and maybe add the new comment to the
list of comments first. I'm not sure what you use those IntegerChangeEvents for
but I am sure you have very valid reasons for them ;) However, both ways of
using events may be cut down to one common thing: the event broadcasting
mechanism! I feel that this is enough to be included in the framework together
with some common events. (Just the way the events are used in the java beans
spec: java.util.EventObject as root for all events and common events like
PropertyChangeEvent that are often used)
2) I didn't spend much though on testing yet. But isn't it possible to assume
(i.e. test) behavior of the sending end using a specialized receiver? This way,
you would just test wheter you received the events you expected and everything
should be fine.
I would really appreciate a final solution that is similar to the usage of
events by the java beans spec. There you have one "root event"
(java.util.EventObject), some commonly used events (e.g. PropertyChangeEvent)
and a naming convention used for introspection. On first look I really, really,
really didn't like your use of reflection in you EventBroadcaster. I'd also
vote for using a much simpler approach as outlined by Martin above. On second
look, I might like an approach that is base on java bean spec's naming
convention: to handle a FooEvent one would have to implement the
FooEventListener interface with a method 'void fooEvent(FooEvent e)'. I'm
currently not sure though whether what I'm saying is completely correct, but
it's at least close enough ;)
Furthermore, I think that we could take the usage of events another step
further (Just some raw ideas here, but maybe worth looking at): Maybe we (and
some core devs) could brainstorm on another thing: Who is responsible for
firing events? This could not only be the user but also the framework itself.
This way, one could implement something like the VetoableChangeListeners where
you can constrain (or validate) model values by dropping in another component
(an event is fired for every model change). I could even imagine, that an event
is fired automatically when one component of a page receives an ajax call.
> 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.
