General Functionality
The first step is to define the functionality of the system you will build. Most systems built with Cocoon publish data in some way. In addition, there might be functions that allow the user to interact with the application in some form. Depending on the type of application, it might be necessary to define areas of information that are then combined into the complete application.
As an example, imagine that you are building a web site application for an imaginary company that produces Rewinders (don't ask us what these are; it's imaginary). Obviously you need functions that allow general information about your firm to be published. However, you have several different areas of information you want to publish, so you need to structure the application. Here are a few areas you might want to define:
General information about Rewinders
News about the company (Rewinder Inc.)
Industry news
Products offered
Jobs
Information for employees only
If you check out some company web sites, you will see that most have this sort of structure. Each area in your web site will have subareas that provide more detailed information. An area such as "Products" will contain all the different types of Rewinders that are offered. The section called "Employees Only" will provide special information about upcoming Rewinders. This information should be available only to someone who has logged on to the system.
After you have designed the application's structure, it is time to think about any interactive components you might need. Perhaps you will need an application form in the "Jobs" area or a feedback form in the "Products" area. In addition, you will need some form of login page for the "Employees Only" area. You also want to know when someone looks at the new "Cool Blue Rewinder," so you specify that you want an email to be sent when that document is viewed.
Depending on the type of application you are building, you might need only publication functions. If your solution is aimed more at processing information, you need more functions that allow interaction with your system.
After you have set up the application's structure, you must work out how navigation through the system is possible. After someone enters the "Products" area, what other areas can he access from there? What happens if he accesses the "Employees Only" area? Working out the navigation and flow can be one of the most time-consuming jobs when designing the application.
A typical application will be a combination of published data and data that flows from the user to the application. After you have defined the site's structure, it is time to think about the content.
The data you want to publish must come from somewhere. Either it is already stored in a file or database, or it will be obtained from external sources at runtime. An area such as "Jobs" will access the current job openings from a database. An application area such as "Industry News" will probably access a news provider to obtain news about the current state of the Rewinder industry. The authentication data is also probably contained in a database. You will need access to it to check such things as the password when a user wants to access the "Employees Only" area.
As soon as you know where the data you want to publish comes from, you need to determine what format it is available in. Of course, it is ideal if the data is supplied in an XML format.
Next you need to define your output formats. Your imaginary company wants to publish its web site in HTML first. In addition, some of the documents are to be in PDF, and you want to offer product descriptions in WML.
Notice that we have not yet talked about a specific technology. Indeed, a first concept does not require any knowledge of how you will realize your application. As soon as you have the concept in place, you can decide which technology to use (in this case, Cocoon) and then move on to defining the actual system architecture.