Author: thomas.heute(a)jboss.com Date: 2007-08-28 09:44:21 -0400 (Tue, 28 Aug 2007) New Revision: 8068 Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/portalapi.xml Log: Fixed the IPC chapter Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/portalapi.xml =================================================================== --- docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/portalapi.xml 2007-08-28 10:08:36 UTC (rev 8067) +++ docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/portalapi.xml 2007-08-28 13:44:21 UTC (rev 8068) @@ -459,7 +459,7 @@ <para>The first version of the Portlet Specification (JSR 168), regretfully, did not cover interaction between portlets. The side-effect of diverting the issue to the subsequent release of the specification, has forced portal vendors to each craft their own proprietary API to achieve interportlet communication. Here we will - see how we can use the event mechanism to pass parameters from one portlet to the other.</para> + see how we can use the event mechanism to pass parameters from one portlet to the other (and only to the other portlet).</para> <para>The overall scenario will be that Portlet B will need to be updated based on some parameter set on Portlet A. To achieve that we will use a portal node event.</para> <para>Portlet A is a simple Generic portlet that has a form that sends a color name: @@ -539,6 +539,12 @@ // We can redirect newEvent = new WindowActionEvent(windowB); newEvent.setParameters(wae.getParameters()); + + // Due to a bug those 2 following lines are required but have no meaning for now + // See: http://jira.jboss.com/jira/browse/JBPORTAL-1604 + newEvent.setMode(wae.getMode()); + newEvent.setWindowState(WindowState.MAXIMIZED); + // Redirect to the new event return newEvent; } @@ -570,6 +576,41 @@ newEvent.setWindowState(wae.getWindowState()); // WindowState.MAXIMIZED</programlisting> </para> --> + <para> + We still need to register our listener as an mbean: + <programlisting> +<![CDATA[<mbean + code="org.jboss.portal.core.event.PortalEventListenerServiceImpl" + name="portal:service=ListenerService,type=test_listener" + xmbean-dd="" + xmbean-code="org.jboss.portal.jems.as.system.JBossServiceModelMBean"> + <xmbean/> + <depends + optional-attribute-name="Registry" + proxy-type="attribute">portal:service=ListenerRegistry</depends> + <attribute name="RegistryId">test_listener</attribute> + <attribute name="ListenerClassName">org.jboss.portal.core.samples.basic.event.PortletB$Listener</attribute> +</mbean>]]></programlisting> + For node events, we also need to declare on which node we want to listen, this is done by modifying + the <literal>*-object.xml</literal> that defines your portal nodes. In this example we want to trigger + the listener each time the window containing the portlet A is actioned. We can add the <literal>listener</literal> + tag to specify that out listener with <literal>RegistryId</literal>=test_listener should be triggered + on events on the embedding object. + <programlisting> +<![CDATA[... + <window> + <window-name>PortletAWindow</window-name> + <instance-ref>PortletAInstance</instance-ref> + <region>center</region> + <height>0</height> + <listener>test_listener</listener> + </window> +...]]> + </programlisting> + Of course we could have added it at the page level instead of the window level. Note that a unique listener + can be specified, the event mechanism is primarily done to let the developer change the navigation state of the + portal, this example being a nice side-effect of this feature. + </para> <note>The portlet 2.0 specification (JSR 286) will cover Inter Portlet Communication so that portlets using it can work with different portal vendors.</note> </sect2>