From portal-commits at lists.jboss.org Wed Mar 21 15:10:08 2007 Content-Type: multipart/mixed; boundary="===============0241557267539040034==" MIME-Version: 1.0 From: portal-commits at lists.jboss.org To: portal-commits at lists.jboss.org Subject: [portal-commits] JBoss Portal SVN: r6793 - docs/trunk/referenceGuide/en/modules. Date: Wed, 21 Mar 2007 15:10:08 -0400 Message-ID: --===============0241557267539040034== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- 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 @@ Content Integration - Since JBoss Portal 2.6 it is possible to provide easy integration= of content within the portal. Up to the 2.4 version + Since JBoss Portal 2.6 it is possible to provide an easy integrat= ion of content within the portal. Up to the 2.4 version content integration had to be done by configuring a portlet to show som= e content from an URI and then place that portlet on a page. The new content integration capabilities allows to d= irectly configure a page window with the content URI - removing the need to configure a portlet for that purpose. It is import= ant 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. + removing the need to configure a portlet for that purpose. + 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 ci= tizen 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. Window content The content of a window is defined by @@ -49,8 +52,8 @@ Content Driven Portlet - 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. + Portlet components are used to integrate content into the port= al. It relies on a few conventions which allow + the portal and the portlet to communicate. Displaying content @@ -66,7 +69,7 @@ In that mode the portlet and the portal will communicate using ei= ther action or render parameters. We have two use cases which are: - The portal needs to configure a new content item.= In that use case the portal will not send special + 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 ren= der parameters will be empty. The portlet can then use render parameters in order to provide navigation i= n 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 @@ content.param. used as= prefix to configure content parameters - The second use case arises when the portal needs = to edit existing content. In such situation + The second use case happens when the portal needs= to edit existing content. In such situation everything works as explained before except that the initia= l set of render parameters of the portlet will be prepopulated with the content uri URI and parameter= s. @@ -314,9 +317,9 @@ Hooking the portlet into the portal - Finally we need to make the portal aware of the fact tha= t the portlet can edit and interpret. For that - we need various descriptors. The portlet.xml descriptor will define our portlet, the - portlet-instances.xml will create a singl= e instance of our portlet and finally the + Finally we need to make the portal aware of the fact tha= t the portlet can edit and interpret content. For that + we need a few descriptors. The portlet.xml descriptor will define our portlet, the + portlet-instances.xml will create a singl= e instance of our portlet. The web.xml descriptor will contain a servlet= context listener that will hook the content type in the portal content type registry. FSContentDrivenPortletInstance - org.jboss.portal.core.servlet.jsp.ContentTypeRegistr= ation + org.jboss.content.ContentTypeRegistration ... ]]> The web.xml descriptor + You don't need to add the listener class into your war f= ile. As it is provided by the portal + it will always be available. --===============0241557267539040034==--