As mentioned at the beginning of this chapter, Cocoon provides many ways of solving certain problems. People new to Cocoon are sometimes overwhelmed by the many possibilities. Often, only one type of component is used to solve a problem when perhaps a different solution would have been better. As an example, when starting out with Cocoon, we often found ourselves writing new transformers when it would have been better to use an action or selector instead.
Here are some tips on when to use what:
Using a given component is better than writing your own.
Use generators when you have an identifiable data source that can be used as the starting point for your pipeline.
Use transformers when you need to manipulate the XML data flowing through the pipeline.
Use actions and selectors to influence the pipeline if their results do not need to manipulate the output document.
Use an action if you want to execute a task that does not influence the XML processing pipeline.
Use a selector if you want to choose between different processing pipelines.
Use XSP for rapid development of a custom generator, and transform it later into a real generator.
This section has looked at a few aspects that are important when you design your Cocoon application. Performance is probably the key factor when the application is actually finished and installed. A well-thought-out concept is a necessary starting point for good design. "Program now; think later" is, in our opinion, not the way to build Cocoon applications. Unfortunately, even writing a great concept beforehand still might not prevent problems from occurring.
So, you've written the concept, designed the architecture, written any needed components, and built the pipelinesand things still don't work as you expected. Here is a two-sentence answer to this problem:
Someone else has already solved your problem! All you need to do is find that person and solution.
Sounds simple, doesn't it? But for many cases, this is true. Problem solving has become easier with the Internet. When we first started using Usenet newsgroups (which were exchanged using UUCP back in those days), we could post our problemsnot just to our colleagues in Paderborn, Germany, but to the whole world! And the Internet has expanded this "knowledge base" so that now it is very probable that someone out there has already had the same problem you are trying to solve.
The Cocoon web site is a good starting place for finding information and help. There you can find mailing lists and archives of past list discussions. Chances are your question is there somewhere. Subscribe to the mailing lists and join the Cocoon community. Appendix C, "Links on the Web," lists links for the Cocoon web site.
Search engines are also a good choice when you are looking for a solution to your problem. However, if you query a search engine, you probably will be swamped with thousands of answers that don't really help. If you already know roughly the area your question applies to, perhaps checking one of the newsgroups is a better way to go. There are newsgroups for most of the subjects in this book, such as XML and XSL. However, there is as yet no newsgroup for Cocoon. Hopefully, you will be able to solve any problem that might arise using one of the listed methods.
Using the information discussed so far should allow you to complete your application concept and design the architecture of your solution, complete with the required Cocoon technologies. Even though most people who look at Cocoon and read this book will already have an exact idea of the type of application they want to build, it is always a good idea to see how other people are using the technology. The following examples might provide some additional ideas for the types of applications you can build with Cocoon.