XML.com

Building XML Portals with Cocoon
Pages: 1, 2, 3

The first step in the build process combines these two base profiles into a global profile. This global profile is the starting point for specific profiles which can be dependent on the user's role or id. The portal administrator can define different default portals for a specific role; for example, a default portal for an administrator or a default portal for a guest. This role profile inherits everything from the global profile and the administrator can then change specific details for the defined role.

The next step is to configure the role profile dependent on the user's configuration. Each user can have her own profile, which in turn inherits from the role profile. Once the profile has been built, it is then cached. When the user logs in next time, the cached version is used instead of recreating it from scratch. In addition, the Cocoon portal keeps track of changes in the profiles. If a base profile is changed, the cached version is invalidated and the next time the user logs in, the changes will take effect and the portal profile is rebuilt.

Here is the actual pipeline from the sitemap that builds the portal. It consists of a specialized portal generator component. As with any Cocoon pipeline the actual layout of the portal is defined using a stylesheet.

<map:match pattern="sunspotdemo-portal">
    <map:act type="auth-protect">
        <map:parameter name="handler" value="portalhandler"/>
        <map:parameter name="application" value="sunspotdemo"/>

	<map:generate type="portal"/>
        <map:transform src="styles/portalHTML.xsl"/>
        <map:serialize/>
    </map:act>
</map:match>

As you can see, the authentication framework is used to protect the portal, so only logged in users can view their portal. The application parameter allows the portal framework to retrieve the configuration for the portal.

Tool for portal management

The Cocoon portal also provides tools so that the portal configuration can be done without having to edit the underlying XML files. As contained in the Cocoon distribution, the example portal brings all the described concepts to life and can be used as the starting point for an individual solution.

Once you have explored the example portal you can start altering it to fit your needs. Obviously you can add new coplets, by defining the pipeline inside the Cocoon sitemap and adding the pipeline as a coplet using the included tool. Because of the way the portal allows new data sources to be included using Cocoon pipelines or URIs, new portals can be built without having to write any code. Another interesting aspect is using an additional stylesheet in the portal generation pipeline to change the appearance of the portal. Cocoon offers components, such as selectors, that can be used to select a different stylesheet depending on the type of browser or other external parameters. Imagine a "late-night" portal, where the layout is changed after 8 PM using a different stylesheet.

Conclusion

The portal and authentication components were donated to the Cocoon project at the beginning of 2002, and they are already being used by several large companies as the base for Intranet based offerings. We are particularly proud of the fact that NASA and large IT companies such as BASF IT Services have seen the advantages of using an open source, XML-based solution to provide a powerful enterprise portal. Because the portal is tightly integrated into the XML publishing platform, it does not break Cocoon concepts and allows the flexibility of XML-XSL publishing to be utilized.

The current portal can be thought of as version 1.0 and has been in production use for over a year. The next version of the portal aims to increase the flexibility of the system and to introduce conformance to existing and emerging portal standards.