[SPRNET-41] Change event wiring mechanism Created: 10/Feb/05  Updated: 29/Jan/15  Resolved: 29/Jan/15

Status: Closed
Project: Spring.NET
Component/s: Spring-NET-CORE
Affects Version/s: 1.0
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Mark Pollack Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SPRNET-21 Event Wiring Prototype Source to Sing... Resolved

 Description   

snip from Alek's email on 1/28/2005.

I'm starting to think we got event wiring backwards first
time around...

Right now we are wiring events within listener definition
and it probably makes more sense to declare them within
event source definition and reference listeners.

To give you an example, what I would like to change is this:

<object name="source" type="Examples.RegexSource,
ExamplesLibrary"/>

<object name="validator" type="Examples.CustomValidator,
ExamplesLibrary">
<listener event="Validating" method="WhenValidating">
<ref class="Examples.StaticEventSource,
ExamplesLibrary"/>
</listener>
</object>

To this:

<object name="source" type="Examples.RegexSource,
ExamplesLibrary">
<event name="Validating">
<list>
<listener type="Examples.CustomValidator,
ExamplesLibrary" method="WhenValidating"/>
<listener object="listenerInstance"
method="WhenValidating"/> </list>
</event>
</object>

<object name="listenerInstance"
type="Examples.CustomValidator, ExamplesLibrary"/>

Let me know what everyone thinks, but this makes a lot more
sense for ASP.Net Page events and it avoids
prototype/singleton related problems this first approach
has.



 Comments   
Comment by Federico Spinazzi [ 29/Mar/05 ]

It has been proposed by Aleks the idea to support <aspects> sections: the <events> one will be in the same spirit. It will allow full control on event propagation, even along the lines of the article at http://www.onboard.jetbrains.com/articles/ldi/print/.

Yes, it will be very loose syntax and I'm sure it should not be the default and only one.

Comment by Rick Evans [ 15/Apr/05 ]

+1 for the approach described above.

Is there a time frame for the implementation of this functionality? Will it be in 0.6 final?

>> Hi,
>>
>> Does everyone agree with the approach to event wiring outlined in
>> sprnet-41
>>
>> http://opensource.atlassian.com/projects/spring/browse/SPRNET-41
>>
>> - Mark

Comment by Mark Pollack [ 29/May/05 ]

The direct registration of listeners inside an object definition will be in the 0.6.0 release. I'm going to work on it now.

The event registration style described by Mike Aizatsky in the above article can use our IEventRegistry implementation as a starting point with a corresponding <events> section. We already had a request in the forum about exposing this event registry functionality via XML. Similar ideas are used in MyXaml, though it seems there you can wire to the event registry directly inside the object definition. Lets push that off for a little bit.

Comment by Mark Pollack [ 23/Jun/05 ]

From Mark's email 5/30

When an object wants to receive events from another object it would use the following syntax...

<object id="sink" type="Examples.SinkType, Examples">
<events>
<subscribe method="HandleEvent">
<source ref="source" event="Click" />
</subscribe>
</events>
</object>

<object id="source" type="Examples.SourceType, Examples"/>

This reads: For the object "sink", subscribe for events using the method "HandleEvent" that come from object source's click event.

We could also support a shorter syntax such as

<subscribe method="HandleEvent" ref="source" event="Click" />

Since the object being referred to is implied to be the source of the events. The 'ref' notation is what Spring.Java is currently using as shorthand for <ref object="objectName"/>.

The other case, when the source indicates who is listening would be

<object id="source" type="Examples.SourceType, Examples">
<events>
<publish event="Click">
<target ref="sink" method="HandleEvent"/>
</publish>
<events>
</object>

<object id="sink" type="Examples.SinkType, Examples">

This reads: For the object "source", publish the Click event to the object sink's HandleEvent method.

There can of course be a mixture of publish and subscribe elements. The outer <events> element is just for logical grouping purposes. Wiring to static events would also be supported with a refType element (I don't think there is a Spring.Java equivalent) as would regexp support in naming conventions for wiring and autowiring in general.

In case the target or source object is not a singleton there should be a way to tell the wiring mechanism to re-use the same instance of the object since otherwise every resolution of the 'ref' tag would result in a new object being created. Maybe <target ref="sink" method="HandleEvent" reusePrototype="true"/> would work. It may be better to put it at a higher level - the publish or events element.

We can also have a separate section that defines how objects created will interact with the event registry - so that sinks and sources do not even have to know about each other directly. With the current functionality on IEventRegistry this would look like

<eventRegistry>
<publish ref="source"/>
<subscribe ref="sink"/>
<subscribe ref="sink" sourceTypeFilter="Examples.SourceType, Examples">
</eventRegistry>

The reason to have a separate section is to avoid having any references in the <objects> XML that would not be understood by the current XmlObjectDefinitionReader. This could potenially go inside the existing <context> section.

Comment by Rick Evans [ 19/Jul/05 ]

Moved to the 1.1 timeframe.

Comment by Federico Spinazzi [ 03/Aug/05 ]

againg on listener depenedency injection, someone came with this marvel:

http://www.codeproject.com/csharp/CommonEventHandler.asp

Comment by Rick Evans [ 11/Sep/05 ]

Ted (Husted) wants this functionality.

This forum post (and the attendant reponses) cover the issue in more detail. Finally, a use case: )

http://forum.springframework.net/viewtopic.php?p=943&highlight=#943

Comment by Aleksandar Seovic [ 17/Nov/06 ]

Moved to 1.2

Comment by Erich Eichinger [ 23/Apr/07 ]

Just read about the OSGi's implementation of the "Whiteboard" pattern.

They expose an event by publishing the event and describing it using optional additional properties. Imho this technique could be used to better control wiring of events in our case and decouples wiring from concrete instances.

This could make "bulk" subscribing a bit more controlled:

<object id="source" type="Examples.SourceType, Examples">
<events>
<publish event="Click" properties="ClickEvent, SubmitButton" />
<events>
</object>

<eventRegistry>
<subscribe ref="sink" sourceProperties="ClickEvent, SubmitButton">
</eventRegistry>

will register the sink only for events with properties "ClickEvent" and "SubmitButton"

Comment by Erich Eichinger [ 23/Apr/07 ]

forgot the link: http://www.osgi.org/documents/osgi_technology/whiteboard.pdf

Comment by Mark Pollack [ 16/Aug/08 ]

This issue just gets delayed and delayed..a sign that there isn't much interest.

Generated at Tue Nov 19 14:55:28 UTC 2019 using Jira 7.13.8#713008-sha1:1606a5c1e7006e1ab135aac81f7a9566b2dbc3a6.