cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From da...@cocoon.zones.apache.org
Subject [DAISY] Updated: Portal: Event Handling
Date Sun, 21 Aug 2005 15:45:49 GMT
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"&gt;
        ...
---     &lt;!-- add a new instance of each class as a subscriber: --&gt;
---     &lt;subscriber-classes&gt;
---         &lt;class name="org.apache.cocoon.portal.event.subscriber.impl.DefaultJXPathEventSubscriber"/&gt;
---     &lt;/subscriber-classes&gt;
---     &lt;!-- add each component as a subscriber (the component should be thread safe):
--&gt;
---     &lt;subscriber-roles&gt;
---         &lt;role name="org.apache.cocoon.portal.samples.location.LocationEventSubscriber"/&gt;
---     &lt;/subscriber-roles&gt;
+++     &lt;!-- add a new instance of each class as a receiver: --&gt;
+++     &lt;receiver-classes&gt;
+++         &lt;class name="org.apache.cocoon.portal.event.subscriber.impl.DefaultJXPathEventReceiver"/&gt;
+++     &lt;/receiver-classes&gt;
+++     &lt;!-- add each component as a receiver (the component should be thread safe):
--&gt;
+++     &lt;receiver-roles&gt;
+++         &lt;role name="org.apache.cocoon.portal.samples.location.LocationEventReceiver"/&gt;
+++     &lt;/receiver-roles&gt;
     &lt;/component&gt;
    ...
        </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

Mime
View raw message