Author: julien(a)jboss.com
Date: 2007-03-21 15:10:08 -0400 (Wed, 21 Mar 2007)
New Revision: 6793
Modified:
docs/trunk/referenceGuide/en/modules/contentIntegration.xml
Log:
improved the content integration chapter
Modified: docs/trunk/referenceGuide/en/modules/contentIntegration.xml
===================================================================
--- docs/trunk/referenceGuide/en/modules/contentIntegration.xml 2007-03-21 19:00:50 UTC
(rev 6792)
+++ docs/trunk/referenceGuide/en/modules/contentIntegration.xml 2007-03-21 19:10:08 UTC
(rev 6793)
@@ -8,11 +8,14 @@
</author>
</chapterinfo>
<title>Content Integration</title>
- <para>Since JBoss Portal 2.6 it is possible to provide easy integration of
content within the portal. Up to the 2.4 version
+ <para>Since JBoss Portal 2.6 it is possible to provide an easy integration of
content within the portal. Up to the 2.4 version
content integration had to be done by configuring a portlet to show some content from
an URI and then place that
portlet on a page. The new content integration capabilities allows to directly
configure a page window with the content URI
- removing the need to configure a portlet for that purpose. It is important here to
note that we do not advocate to
- not use portlet preferences but rather we advocate the configuration of content to be
managed at the portal level.</para>
+ removing the need to configure a portlet for that purpose.</para>
+ <note>We do not advocate to avoid to use portlet preferences, we rather advocate
that content configuration managed at the portal level
+ simplifies the configuration: it helps to make content a first class citizen of the
portal instead of having an intermediary
+ portlet that holds the content for the portal. The portlet preferences can still be
used to configure how content is displayed
+ to the user.</note>
<sect1>
<title>Window content</title>
<para>The content of a window is defined by
@@ -49,8 +52,8 @@
</sect1>
<sect1>
<title>Content Driven Portlet</title>
- <para>Portlet components are used to integrate content in the portal. It
relies on a few conventions which allow
- the portal and the portlet to communicate between each other.
+ <para>Portlet components are used to integrate content into the portal. It
relies on a few conventions which allow
+ the portal and the portlet to communicate.
</para>
<sect2>
<title>Displaying content</title>
@@ -66,7 +69,7 @@
In that mode the portlet and the portal will communicate using either action or
render parameters. We have two use cases
which are:
<itemizedlist>
- <listitem>The portal needs to configure a new content item. In that
use case the portal will not send special
+ <listitem>The portal needs to configure a new content item for a new
window. In that use case the portal will not send special
render parameters to the portlet and the initial set of render parameters
will be empty. The portlet can
then use render parameters in order to provide navigation in the content
repository. For example the portlet
can navigate the CMS tree and store the current CMS path in the render
parameters. Whenever the portlet has decided
@@ -78,7 +81,7 @@
<listitem><emphasis>content.param.</emphasis> used
as prefix to configure content parameters</listitem>
</itemizedlist>
</listitem>
- <listitem>The second use case arises when the portal needs to edit
existing content. In such situation
+ <listitem>The second use case happens when the portal needs to edit
existing content. In such situation
everything works as explained before except that the initial set of render
parameters of the portlet
will be prepopulated with the content uri URI and
parameters.</listitem>
</itemizedlist>
@@ -314,9 +317,9 @@
</sect3>
<sect3>
<title>Hooking the portlet into the portal</title>
- <para>Finally we need to make the portal aware of the fact that the
portlet can edit and interpret. For that
- we need various descriptors. The <emphasis>portlet.xml</emphasis>
descriptor will define our portlet, the
- <emphasis>portlet-instances.xml</emphasis> will create a single
instance of our portlet and finally the
+ <para>Finally we need to make the portal aware of the fact that the
portlet can edit and interpret content. For that
+ we need a few descriptors. The <emphasis>portlet.xml</emphasis>
descriptor will define our portlet, the
+ <emphasis>portlet-instances.xml</emphasis> will create a single
instance of our portlet. The
<emphasis>web.xml</emphasis> descriptor will contain a servlet
context listener that will hook the content
type in the portal content type registry.</para>
<programlisting><![CDATA[
@@ -369,12 +372,14 @@
<param-value>FSContentDrivenPortletInstance</param-value>
</context-param>
<listener>
-
<listener-class>org.jboss.portal.core.servlet.jsp.ContentTypeRegistration</listener-class>
+
<listener-class>org.jboss.content.ContentTypeRegistration</listener-class>
</listener>
...
</web-app>
]]></programlisting>
<para>The web.xml descriptor</para>
+ <note>You don't need to add the listener class into your war file.
As it is provided by the portal
+ it will always be available.</note>
</sect3>
</sect2>
</sect1>
Show replies by date