cocoon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject cvs commit: cocoon-2.1/src/documentation/xdocs/developing/portal index.xml
Date Wed, 12 Nov 2003 10:39:06 GMT
cziegeler    2003/11/12 02:39:06

  Modified:    src/documentation/xdocs/developing/portal index.xml
  Adding some info about the new portal
  Revision  Changes    Path
  1.10      +94 -1     cocoon-2.1/src/documentation/xdocs/developing/portal/index.xml
  Index: index.xml
  RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/developing/portal/index.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- index.xml	12 Oct 2003 13:16:32 -0000	1.9
  +++ index.xml	12 Nov 2003 10:39:06 -0000	1.10
  @@ -22,6 +22,99 @@
     which means that the engine can still change in every aspect.</p>
  +  <s1 title="Features">
  +  <p>The portal framework is a portal server that runs inside Cocoon - or to be more

  +     precise inside the Cocoon servlet. It contains a portlet container that is
  +     called coplet container. Coplet stands for <em>Cocoon Portlet</em> and
is the 
  +     Cocoon equivalent to portlet.</p>
  +  <p>Due to the highly extensible nature of Cocoon, the portal is configurable and

  +     extensible as well and provides many hooks and switches to easily adapt the 
  +     portal for specific needs. As the portal is integrated in Cocoon it has the 
  +     advantage that all features of Cocoon can easily be used. Cocoon is very strong 
  +     in fetching data from various source and delivering it in the various output formats

  +     requested by different clients (like HTML, WML, PDF etc.).</p>
  +  <p>With the latest features, like the form handling framework, the authentication
  +     and the flow concept, it is very easy to develop and maintain complex applications
  +     Cocoon. And these applications can in turn be viewed as portlets inside a portal.

  +     But even by just using the flexible pipeline concept from Cocoon it's possible to

  +     develop complex and nice looking portals.</p>
  +  <p>The portal view is described by an XML document. This document contains the
layout and 
  +     the ordering of the selected portlets. The layout is a tree-like structure, it can
  +     example contain rows, columns or tabs in any ordering or nesting. This allows the

  +     description of the portal view in a parent-child relationship. Even complex layouts

  +     with portlets spanning several columns or tabs inside a single column are possible.</p>
  +  <p>For each portlet a placeholder is defined in the XML document. Special components,

  +     so called renderers, are used to generate (or render) the portal view. Each layout
  +     (each row, column etc.) has an configurable renderer associated that generates the
  +     of the portal for this layout object. For example a renderer for a row could create
  +     required HTML tags.</p>
  +  <p>The renderers can either directly generate the required format (like HTML) or
they can 
  +     create an XML document that is later transformed by Cocoon to the format requested
  +     the client using a stylesheet. This depends on the requirements of the application
  +     how it is developed. The output of all involved renderers is aggregated and this creates

  +     the (layout) document for the portal view.</p>
  +  <p>After the layout is rendered, the placeholders for the different portlets are
  +     with the content from the portlets. Therefore the portlet container is asked to deliver

  +     the content of a given portlet and this content is inserted at the correct places

  +     in the portal view.</p>
  +  <p>In Cocoon a portlet can have different types:</p>
  +  <ul>
  +    <li>Static: Reading a static file, like an HTML document or a PDF file</li>
  +    <li>URI: Reads information using a URI</li>
  +    <li>Pipeline: Uses the Cocoon pipelining concept to dynamically generate the
  +    <li>Custom Types: If the need arises, it's possible to develop a custom type
and use it.</li>
  +  </ul>
  +  <p>In Cocoon, the use of the pipeline type is possibly the most common one right
  +  <p>The complete configuration (the portal view, the available portlets, their settings)
is done 
  +     using XML documents. So it is possible to develop a portal application by just changing
  +     configuration without any Java coding. However if the need arises nearly any part
of the 
  +     portal can be changed/extended by writing an additional component (in Java) and plugging
  +     into the portal engine (by configuration). For example, one component - the profile

  +     manager - is responsible for getting the profile of the current user (the user associated

  +     to the current request). A profile contains the portal view (layout, ordering etc.)
and the configuration of the 
  +     different portlets for this user.</p>
  +  <p>There is one implementation that reads this profile from any database accessible
  +     Cocoon on a per user base. The profile can for example be stored in a database, on
  +     file system or in a WebDAV repository. Therefore every user has their own portal view

  +     and can customize this to their needs. Another implementation is more <em>static</em>.

  +     This means every user gets the same layout and the same portlets. So in fact the portal

  +     can be used for web pages that have a portal like structure but don't have any 
  +     personalization at all.</p>
  +  <p>All changes that may occur inside a portal are propagated through a flexible
event management.
  +     The event handling follows the usual publisher/subscribe pattern. A component, for
example a 
  +     portlet, that is interested in a special event can subscribe for all events of this
  +     The component is notified when such an event occurs and can react on this event by
  +     its status, sending new events or whatever is appropriate.</p>
  +  <p>This event handling is for example used to change preferences, to change the
portal profile 
  +      or to change the status of a portlet. For example, events can be sent to add a new
  +      to the portal view or to minimize a portlet. In addition this event handling can
be used 
  +      for communication between portlets. Imagine a portlet where the user chooses a city
he wants 
  +      to travel to. This selection is broadcast to other portlets using the event handling.
  +      portlet, displaying the current weather information of a city, receives this event
and displays 
  +      the weather information for the city selected in a different portlet. This is a very
  +      example for inter portlet communication but it shows the potential.</p>
  +  <p>As Cocoon and therefore the portal as well is based on the request response
cycle, a request 
  +     for displaying the portal view triggers two tasks that are executed one after the
  +     The first task is the event handling phase. In this phase all events that are triggered
by the 
  +     request are processed and published. For example if the user clicks on the minimize
button of 
  +     a portlet, a request is sent to Cocoon and a minimize event for the portlet is published

  +     triggering the status change by some receiver of the event.</p>
  +  <p>This processing of the request information can trigger new events that are published
as well and
  +     so on. When all events are published and consumed, the second task is executed that
  +     renders the portal view as described above. And the portal view is sent as a response
back to 
  +     the client. On the client the user can navigate through the portal and trigger some
action like 
  +     minimizing, enlarging a single portlet to a full screen mode temporarily hiding the
  +     portlets and so on.</p>
  +  <p>Some installations of the Cocoon portal are going far beyond these usual use
cases. They use 
  +     the included components for example to create a view to a complete web application
running on 
  +     a different server. One single portlet shows the application and a click/action in
this portlet 
  +     triggers a request to Cocoon that is forwarded to the distant application and the
new <em>state</em>
  +     of the application is then displayed in the portlet again.</p>
  +  <p>But by using Cocoon this can even go further: stylesheets can be used to change
the layout 
  +     of the integrated application. So you can give an application a totally different
lock and feel 
  +     using a portlet.</p>
  +  <p>And - of course - SoC (separation of concerns) applies to developing portals
with Cocoon as
  +     well, so you can develop your portal in groups each group concentrating on their concern.</p>
  +  </s1>

View raw message