| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> |
| <html> |
| <head> |
| <META http-equiv="Content-Type" content="text/html; charset=UTF-8"> |
| <title>Webapps Developer Documentation</title> |
| <link href="http://purl.org/DC/elements/1.0/" rel="schema.DC"> |
| <meta content="Overview" name="DC.Subject"> |
| <meta content="Carsten Ziegeler" name="DC.Creator"> |
| </head> |
| <body> |
| |
| <h1>Overview</h1> |
| |
| <p>This section contains several documents about developing a portal with Cocoon.</p> |
| |
| <p>The <a href="../webapps/portal.html">portal framework</a> is a stable |
| portal framework that uses the authentication framework. It can |
| be used to quickly develop portal applications.</p> |
| |
| <p>The new <a href="portal-block.html">portal engine</a> is a new |
| implementation of a portal engine which focuses on more flexibility |
| and ease-of-use. In addition it supports the JSR-168. The current state of |
| this engine is <em>alpha</em> which means that the engine can still change |
| in some aspects.</p> |
| |
| |
| |
| <h1>Features</h1> |
| |
| <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 framework |
| and the flow concept, it is very easy to develop and maintain complex applications with |
| 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 for |
| 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 object |
| (each row, column etc.) has an configurable renderer associated that generates the output |
| of the portal for this layout object. For example a renderer for a row could create the |
| 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 by |
| the client using a stylesheet. This depends on the requirements of the application and |
| 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 replaced |
| 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 content</li> |
| |
| <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 now.</p> |
| |
| <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 the |
| 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 it |
| 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 from |
| Cocoon on a per user base. The profile can for example be stored in a database, on a |
| 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 kind. |
| The component is notified when such an event occurs and can react on this event by changing |
| 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 portlet |
| 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. Another |
| 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 simple |
| 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 other. |
| 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 actually |
| 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 other |
| 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> |
| |
| |
| </body> |
| </html> |
