This chapter is from the book
This chapter is from the book
This chapter is from the book
Different Types of Applications
Cocoon lends itself to being used to build a variety of solutions. Although Cocoon is aimed primarily at the XML publishing sector, adding your own components lets you expand Cocoon into a complete middleware architecture.
In the past we have worked on building a commercial solution that provides additional (and sometimes customer-specific) components needed to provide a complete solution. We added components and functionality to Cocoon without throwing away a single Cocoon concept. This shows the extensibility of the architecture.
To give you some idea of what perhaps you can do to solve a specific problem, here are some of the extensions we have written to provide the various solutions we have built with Cocoon:
Components for authentication and user administration
Portal framework components
A complete XML/XSL-based content management system
Integration components for a commercial XML database
System management components
Although these components were not written as part of the Cocoon project, some of them will find their way back into Cocoon and hopefully will be available in the not-too-distant future.
Using Cocoon and the additional components allows you to build applications such as portals, flexible publishing systems, and web sites. Because Cocoon can process XML data, you can also build solutions that can receive complete XML documents as input and process them using pipelines.
Let's look at some of these application types in more detail. The most common Internet application is the web site, where information is published as HTML. This type of application becomes more complex to develop when the information is stored in external systems such as databases and when additional formats such as PDF are required. The web site needs to be extended into a network publishing application to provide these advanced capabilities. When several different types of users are accessing the system, some form of personalization is called for. The term portal is often used to describe this type of application. This chapter concludes with a look at how to use Cocoon to build portals.
Using Cocoon to Build Web Sites
One of the most common uses of Cocoon is as a system for building web sites. After all, that is its main function. Many web sites already use Cocoon; they are listed on the Cocoon web site. We discussed a web site example earlier in this chapter. Now we will add to the information that was discussed there.
Remember that Cocoon organizes a web site's content using a sitemap. Although it is possible to define a pipeline for each document your web site will serve, this would result in a sitemap that becomes very hard to maintain. Therefore, you need to define pipelines that can handle similar types of content, perhaps split into different areas. Look into how you can use wildcards in the sitemap as a method of combining several documents into one pipeline.
Make sure the layout developer (the author of the stylesheets) uses a tool that can perform XSL transformations on some sample data for that format. You should provide the author with sample data to use. It will be easier for him to test individual stylesheets this way instead of having to use Cocoon each time.
Another important point is to make sure the layout deployers use a tool that either already uses the Xalan XSLT component or that lets you use it additionally. If the tool allows a version of Xalan to be used, make sure you use the same version as the one in the Cocoon you will be running. Which tool is best suited for the job depends largely on exactly who will be using it and for what purpose. We have provided a list of relevant links to tools in Appendix C.
Although your first-version web site might only read its content from XML files and publish to a single format such as HTML, one day you will want to use something more advanced to store your data, such as a database. You might also need to integrate external systems such as mainframes into your application. In addition, there might be demand for additional formats as users use devices such as mobile phones to access your solution. The web site must therefore be extended into a network publishing application.
Network Publishing Applications
Although this is only a different way of defining something, we use the term publishing application to emphasize that the data you want to display is actually stored somewhere, and we don't mean in a file. A publishing system might generate reports from data that is obtained from a database, for example. It then might manipulate the data in some way, perhaps to generate different views and then publish that data in one or more formats.
Areas you will want to look into include the Cocoon components that allow you to access data from a database or external systems such as a remote XML server via HTTP. You will also want to learn more about standards such as XSL:FO. After it is formatted this way, your data can be laid out in different output formats, such as PDF or PostScript.
Publishing systems might be the first time you need to publish data that is dependent on the type of end device. For example, you could allow mobile phone users to access only the most important information while allowing browser users to access the full beauty of your web site.
In our experience, using Cocoon as a publishing system for specific data is an ideal way to introduce the technology into a new area. Applications such as a report generator, which reads data from a database, consolidates it, and then presents that information in HTML and PDF, can be built in an isolated fashion that does not intrude on given software structures. The first little application we built with Cocoon was a front end to an internal database we had at that time containing work reports. The solution read the data from the database dependent on a query parameter and then presented an overview of the data in the various formats. As a prototype showing what could be done with Cocoon and how flexible it was, this was an ideal solution.
Publishing systems might be the first time you also need to integrate something like user authentication and personalization—allowing only certain people to access the data. This brings us to the next application form—the portal.
Portals
Although you probably think of something like myYahoo or myAOL when the term portal is used, portals can actually be a lot simpler. We refer to this type of application whenever some form of user authentication is necessary to access information or when information can be individually personalized. This personalization can range from changing the color of a single document to configuring external news sources in a news portal.
In our portal example, built over several chapters, we have already seen how it is possible to build a portal using Cocoon. Nevertheless, and because we know that some readers might jump right to this section, we will go over some of the main points again and in a more general context.
In order for personalization to be possible, we need to be able to recognize the user when he accesses the portal. Most portals require some form of authentication, such as entering a user ID and password. This data is then matched against a repository, such as a database, and the user is rejected if there is no match. Each user therefore requires an entry in the database, and the application perhaps also needs to cater to an anonymous user (a user without a login). After the user is authenticated, the application will want to allow the user to access the different areas in the portal without having to log in again. Look into ways of creating a session when running inside a servlet engine in order to do this. It will also be necessary to recognize a returning portal user so that he does not have to log in each time he accesses some part of the portal. An appropriate action component can solve this problem.
Another important step is to define the portal structure. What information will be available to the user after he has logged in? Will each user have an individual profile, or will the portal cater to only specific groups of users? As soon as this has been decided, a suitable XML format for the profiles can be defined. The profile should then contain information relevant to the personalization (such as colors) or to the individual preferences in regard to the types of information to be displayed.
Therefore, the first step of building the portal is to define where the user data and the portal profile are to be stored. Then the application needs to define and set up a pipeline in Cocoon for the authentication. One way of doing this is to have an HTML form send the user ID and password to Cocoon and then use the sql_transformer to select the user and profile from the database.
If the portal profile contains data on the types of information that are to be displayed, this information must be fetched and integrated into the profile so that it is complete before it reaches the stylesheet. Look into using content aggregation as a way of doing this. Each different data source will then return information that is added to the user's profile, so that the end result will be a complete portal in XML.
After the profile has been selected and all the data fetched from the various sources, the complete profile can then be transformed into a specific look and feel using a stylesheet. The stylesheet can access specific details contained in the individual profile and format the output as necessary.
If the personalization is based on the user who accesses the site, you need to define what types of information the user can change and how the presentation should be affected by, say, his age. If you will be providing a different layout for teenagers than for middle-aged people, you will need to define the criteria by which this can be decided. Writing a new component such as a selector is an ideal way of doing this.
Think about whether you want to change the presentation dependent on other factors, such as the time of day or the weather. Say you are building a stock-quote portal and you present the current market chart (say NASDAQ) on your front page. After the NASDAQ closes for the day, it might be a good idea to present a different chart, such as from Asia. So if you want to switch content and presentation dependent on the time of day, look into the Cocoon selector component as a way of doing this.
If you are thinking about building a late-night portal, in which the presentation changes after a certain hour, remember that your user might be living in a different time zone, so it might be the middle of the day for him when you select the late-night presentation.