cocoon and xml

The cocoon project has taken the concepts of publishing using xml/xslt and implemented them in an effective platform.This has been achieved by not only providing the transformation capabilities ,but also looking at some of the wider issues of the separation of logic and presenation along with multichannel delivery. Cocoon  actually uses only part of the avalon infrastructure-namely,framework,excalibur,and logkit. All the cocoon core components are based on avalon components so that they can easily make use of the infrastructure provided. The fundamental roles that cocoon defines for its components are configured in a file called cocoon.roles,which can be found in the org/apache/cocoon folder of the source tree. This file is really used only to configure the roles and is not used to configure components,hyence it is compiled into the runtime cocoon.jar. Another,fra more relevant,file is cocoon.xconf.This file is used to proviode specific configuration data for components. You can find cocoon.xconf in the web-info folder.Here you will find parameters for configurinmg database connection pool sizes,the logicsheets that are avaible to the system,memory pool sizes,sitemap configuration and so on.

Although cocoon is typically thought of as a servlet, this is really an incorrect stance. The typical way cocoon is accessed is via a servlet. To provide a high level of flexibility and separation of concerns,cocoon uses  a pipelin processing model.This basically means that a requesty goes through a sequential chain of events to generate a response. The chain of events that take places is configured via a configuraion file the sitemap. Inside the pipeline, a clearly defined sequence of basic steps has been identified that apply to the processing of request:@request matching and selection,@sax generation. The generation step generates a stream od sax events from a data source.@transformation,@serialization.  The sitemap is the name of the file that contains the configuration information for the pipelines that an application requires. The main cocoon sitemap file is found in the root of the cocoon web application folder and is called sitemap.xmap.

What a view does is allow the stream to be captured and transferred to an alternative processing chain. A simple view would capture the generator stream and serializer that to xml;more complex views might capture the results of a transformation or aggregation. The principle of views can be extended and offer ways of debugging applications by capturing raw output at various stages of processing.

Whereas generators allow you to implement logic at the time data is collected,transformers allow you to implement logic on the data that is already collected by a generator. Aggregation is something that is extremely useful when dealing with disparate data sources that need to be combined into a single page. You can implement aggregation in cocoon in various ways:#CInclude#XInclude#pipeline aggregation. Sitemap parameters are an extremely powerful mechanism in cocoon. The concept actually has two meanings,referring both to parameters that are passed to sitemap component, and to parameters that are returned by certain components. As used in the first sense, stiemap parameters are actually avalon objects called paramters.A parameter object is basically equivalent to java.util.Properties, although there are some differences;parameters are read-only and are created by specifying <map:parameter>tag in the sitemap. When a request uri matches a pipeline, a new map object is created by the matcher(more precisely, the map object is returned to the piepline by the matcher). This map object contains a list of the substitution variables. Each time there is a new <map:match> or <map:act> tag, a new map object is created that exists in the pipeline until the corresponding close tag.

An action is a java component that can implement logic and interact with the sitemap via sitemap parameters. An action can get data from the sitemap via a paramters object. Like a matcher, it can also return data via a map object. Actions also have an effect on the pipeline merely based on whether they return a map object or null object. if a valid object is returned, all steps inside the <map;act> block will get executed,with execution terminating after the last step. If a null object is returned, all steps inside the <map;act> block will be ignored, but all actions following it will be executed.

A composable component is one that can make use of other components. The principles of separation of concerns and inversion of control as exercised in avalon mean that a component can not directly use the implementation of another component.Iy must be done through a ComponentManager.Implementaing the composable interface allows a component to gain access to the ComponentManger and thus access implementation via the role method.A component that implements the Composable interface will also implement the compose() method. This gets called as part of the component lifecycle and is where the component can gain access to the ComponentManger and from that to implementation of the other com[ponents. The Configurable interface is another common one to be implemented in Cocoon components. This is because many components need to be able to pick up configuration settings. ObjectModelHelper is a highly useful class because it gives your classes such as actions,access to the Context,Request,and Response objects. The SitemapModelComponent interface is implemented by generator,readers and transformers. It declares the setup() method that these components can override. The EJB container naturally, controls EJBs, providing services such as transaction management,security,remote client interaction,database connectivity and life-cycle management. Web components basically servlets and JSP pages are controlled in the web container.

Cocoon contains two primary components that can help with this process:JSPReader and JSPGenerator. These components are supported by another component,JSPEngine. This provides the link to a servlet engine. The servlet engine is called to compile and generate the JSP page;JSPR eader just passes the results through the output stream,and JSPGenerate takes the results of the JSP compilation process and passes the results down the pipeline as a stream of SAX events.