A document has been updated:
http://cocoon.zones.apache.org/daisy/documentation/597.html
Document ID: 597
Branch: main
Language: default
Name: Portal: Event Handling (unchanged)
Document Type: Document (unchanged)
Updated on: 8/21/05 3:45:31 PM
Updated by: Carsten Ziegeler
A new version has been created, state: publish
Parts
=====
Content
-------
This part has been updated.
Mime type: text/xml (unchanged)
File name: (unchanged)
Size: 13868 bytes (previous version: 13332 bytes)
Content diff:
(10 equal lines skipped)
<h1>Introduction</h1>
--- <p>The event handling is a central mechanism used in the portal engine.
Every
--- change (changes in status or layout, links etc) is propagated through an
event.
--- The portal uses the publisher/subscribe paradigm, so each component that is
--- interested in a specific event can subscribe itself for this type of event.
In
--- addition each component can send out events.</p>
+++ <p>The portal engine uses an event based mechanism for communication. Each
and
+++ every change or action is propagated through an corresponding event.
Examples
+++ are changes in status, changes in the layout or the user clicking a
+++ link/submitting a form. The portal uses the publisher/subscribe
paradigm: each
+++ component interested in a specific event can subscribe itself for this type
of
+++ event. And of course each component is able to send out events.</p>
<p>The processing of a portal request (a request send to the Cocoon portal)
is
divided into two phases: event handling and rendering. In the first phase
all
(55 equal lines skipped)
<pre>EventManager manager = null;
try {
manager = serviceManager.lookup(EventManager.ROLE);
--- manager.getPublisher().publish(event);
+++ manager.send(event);
} finally {
serviceManager.release(manager);
}
(80 equal lines skipped)
<pre>EventManager manager = null;
try {
manager = serviceManager.lookup(EventManager.ROLE);
--- manager.getRegister().subscribe( myComponent );
+++ manager.register( myComponent );
} finally {
serviceManager.release(manager);
}
</pre>
--- <p>The component you subscribe must implement the Subscriber interface:</p>
+++ <p>The component you subscribe must implement the Receiver interface which
is
+++ just a marker interface! But as the component is just interested in some
+++ particular events, the portal uses a reflection based mechanism to query the
+++ component: whenever a component registeres itself, the event manager uses
+++ reflection to search for all methods with the name inform and a signature
with
+++ two parameters: the first being the event class and the second the portal
+++ service. This is an example:</p>
--- <pre>Subscriber interface:
+++ <pre>public class MyComponent implements Receiver {
--- public Class getEventType();
+++ public void inform(CopletInstanceEvent event, PortalService service);
+++ }
+++ </pre>
--- public void inform( Event event );
--- </pre>
+++ <p>Now each time a CopletInstanceDataEvent occurs, this method is call. If
the
+++ component is interested in different events, it can implement several inform
+++ methods each with a different signature.</p>
--- <p>The getEventType() method returns the class/interfaces of the events the
--- component is interested and each time such an event occurs, the inform()
method
--- is invoked.</p>
+++ <p>An example for such a component, is a available component in the portal
+++ subscribing for all events dealing with coplets, so it returns uses
+++ <em>CopletInstanceEvent</em> as the class in the inform method.</p>
--- <p>For example one central component in the portal subscribes for all events
--- dealing with coplets, so it returns <em>CopletInstanceEvent</em> as the
class
--- (interface) in getEventType().</p>
---
<h1>Inter Coplet Communication</h1>
<p>A very interesting feature of the portal is inter-coplet communication.
The
(82 equal lines skipped)
logger="portal"
role="org.apache.cocoon.portal.event.EventManager">
...
--- <!-- add a new instance of each class as a subscriber: -->
--- <subscriber-classes>
--- <class
name="org.apache.cocoon.portal.event.subscriber.impl.DefaultJXPathEventSubscriber"/>
--- </subscriber-classes>
--- <!-- add each component as a subscriber (the component should be
thread safe): -->
--- <subscriber-roles>
--- <role
name="org.apache.cocoon.portal.samples.location.LocationEventSubscriber"/>
--- </subscriber-roles>
+++ <!-- add a new instance of each class as a receiver: -->
+++ <receiver-classes>
+++ <class
name="org.apache.cocoon.portal.event.subscriber.impl.DefaultJXPathEventReceiver"/>
+++ </receiver-classes>
+++ <!-- add each component as a receiver (the component should be
thread safe): -->
+++ <receiver-roles>
+++ <role
name="org.apache.cocoon.portal.samples.location.LocationEventReceiver"/>
+++ </receiver-roles>
</component>
...
</pre>
<p>In the sample configuration above, one class is subscribed (the
--- <em>DefaultJXPathEventSubscriber</em>) and one Avalon component (the
--- <em>LocationEventSubscriber</em>).</p>
+++ <em>DefaultJXPathEventReceiver</em>) and one Avalon component (the
+++ <em>LocationEventReceiver</em>).</p>
--- <p>So, if you write your own events and your own subscribers you can either
+++ <p>So, if you write your own events and your own receivers you can either
dynamically add them during execution or statically add them by
configuration as
shown above.</p>
(15 equal lines skipped)
Fields
======
no changes
Links
=====
no changes
Custom Fields
=============
no changes
Collections
===========
no changes
