Apache Cocoon
| Cocoon | |
|---|---|
| Basic data
|
|
| Maintainer | Reinhard Poetz et al. |
| developer | Apache Software Foundation |
| Publishing year | February 20, 2006 |
| Current version |
2.2.0 ( May 15, 2008 ) |
| Current preliminary version | 3.0.0-alpha-3 (June 8, 2011) |
| operating system | Platform independent |
| programming language | Java |
| category | Web framework |
| License | Apache license |
| cocoon.apache.org | |
Cocoon is an XML publishing system from the Apache Software Foundation . This framework was created to save data in XML form and to output it formatted using XSL . XHTML , PDF , RTF and many more (see below) can be used as output products for XML data .
"Cocoon is a 'Publishing Framework Servlet' that [...] transforms an XML source document into any target format depending on the requesting client."
Cocoon's source code falls under the Apache license and is therefore free software .
Emergence
Cocoon was written (started) by Italian student Stefano Mazzocchi in 1998 while watching the science fiction film Cocoon , after which the system was named.
introduction
The concept of Cocoon is based on a new approach compared to other web-based frameworks. In HTML documents, the layers of content, layout and programming logic are usually permanently linked to one another, often even coded in a file. Cocoon takes a different way of publishing the information. The three layers mentioned are strictly separated from each other and must be processed in separate files. In the beginning, this means more work for the developer when creating the website, since he has to create and maintain three files. This additional effort can be compensated for several times in the course of development in large projects, since individual logic or layout parts can be easily exchanged by changing the corresponding file, integrated into other projects and thus reused.
To implement the concept of separating the individual layers in Cocoon, XML was chosen because XML consistently meets these requirements. The management, which controls every part of the development, stands above the three layers.
In a Cocoon project, for example, a designer could be responsible for a stylesheet (layout), a programmer for the logic and an editor for the content of an XML file. Furthermore, Cocoon was developed with Java, which is why it is platform-independent. Cocoon also supports the control of the page flow (Cocoon Control Flow), EAI requirements and the establishment of web portals. In addition, it integrates seamlessly into the J2EE world.
functionality
Technically, Cocoon is based on servlet technology. A servlet is a Java class that receives and processes client requests to web servers. A response is generated within this processing, which is then passed on to the web server. Tomcat from the Apache Software Foundation is the reference implementation of this technology, which uses the Java programming language from Sun Microsystems.
With Cocoon, not only can dynamic web applications be created, local use is also possible. Apache Lenya is a content management system based on Cocoon.
In addition, Cocoon brings a portal engine with at which portals create can.
construction
Cocoon has a completely object-oriented functional model. This makes it very easy to integrate new components or replace existing ones. All components are based on the Apache Excalibur model , which specifies the exact structure of each component. It is possible to develop your own components that can be integrated into the existing model through inheritance.
Cocoon 2
With Cocoon 2.x, the developers decided to re-implement Cocoon in order to learn from the mistakes of version 1.x. The internal architecture and the concept of Cocoon were changed. The flexible sitemap has been added, with which processing instructions can be carried out in any order. The performance has also been significantly improved - on the one hand by faster caching technology and on the other by optimized processing of the XML documents: Instead of building complex tree structures with the DOM parser, the event-driven SAX parser is now used.
With this re-implementation, Cocoon now has two pillars: While the older concepts still exist, the re-implementation has added many new, necessary and helpful techniques. Due to the backward compatibility, it is possible to use both older and newer techniques or even to combine them.
Cocoon 2.2
Since May 2008 the fundamentally revised version 2.2.0 of Apache Cocoon is marked as "stable". While the previous versions were based on the now discontinued Apache Avalon framework, the new version is based on Spring . Furthermore, the build tool Ant was replaced by Apache Maven .
Like its predecessors, Cocoon 2.2 is designed to be very component-oriented. The development now takes place in independent modules, so-called blocks . This new architecture offers considerable advantages, for example through the Rapid Class Reloader , which automates the compilation of JAVA source code, or the possibility of integrating the functionality of the Spring framework. Handling (creation of blocks, communication between blocks, Eclipse integration, etc.) has also been significantly improved compared to its predecessors.
Components
Cocoon is implemented on the basis of the Java framework Spring and can be expanded with your own Java components as required. Cocoon's real work is done in pipelines. The pipeline consists of up to seven component types, each of which is used for logic or processing.
Sitemap
The sitemap is the focus of every Cocoon application. The sitemap is an XML file called sitemap.xmap. This is always in the root directory of the current project. Subdirectories of the project can contain a subsitemap. It defines the different Cocoon components and the client / server interactions in the so-called pipelines. The job of a sitemap is to decide what happens when a particular request is made by the user or the system, e.g. B. calling up a specific website.
To recognize which actions are carried out after a certain request, the sitemap has so-called matchers .
Matcher
User requests (requests such as URLs or cookies) are tested against the matcher in the sitemap until a match is found. The response then results from the execution of the tasks belonging to the matcher. The matchers themselves contain sequences of characters that correspond to wildcards or regular expressions .
Selector
The selector evaluates certain information from the request. Usually an HTTP header is transmitted when a website is requested. A selector is a kind of switch instruction.
Approx. 8 selectors are available, here only the most important:
- BrowserSelector (check of the browser used)
- HostSelector (check of the host parameter of the HTTP request)
- ParameterSelector (checking of a defined parameter within cocoons)
- HeaderSelector (checking the content of the HTTP request header)
pipeline
The matcher and its associated tasks are called an XML pipeline . A typical pipeline consists of a generator, possibly followed by one or more transformers and finally a serializer.
The tasks within the pipeline are processed serially. Matchers are the link between a request (by a client to Cocoon) and the subsequent operations of the pipeline to be carried out.
The following figure illustrates the concept of the pipeline, in which a request is first sent to the sitemap, then the appropriate matcher is called and the tasks are carried out one after the other. The tasks that have already been mentioned several times are carried out by so-called components that are integrated into Cocoon. The components used within the pipeline are a generator, a transformer and a serializer.
Generators
The generator is the starting point of the processing component of the pipeline. Generators have the task of generating structured data, e.g. B. XML data or the contents of a database to convert into a SAX stream. This is then passed on to the transformer. There can only be one generator per pipeline.
Transformers / transformers
Transformers convert the XML elements generated by the generator. There can be multiple optional transformers per pipeline. Each transformer often only takes care of certain elements of the SAX stream. Several transformers can be executed one after the other to create a document with content and layout. A pipeline without transformers is also possible. The transformer is particularly useful for websites with multilingual content (internationalization). A transformation step is often carried out with the help of an XSLT stylesheet.
Serializer
The serializer converts the output of the transformer, the SAX stream, into a target document in which the content can then be represented. The output takes place as a stream ( binary or character) and is sent as a response. Usually a pipeline ends with the serializer.
Reader
The reader is suitable for very simple pipelines, since files can be returned to the client without further processing. It is mainly useful for non-XML files in a Cocoon site.
Two readers are already included with Cocoon:
- ResourceReader (for reading binary data)
- JSPReader (for reading output from JSP pages)
Action
An action is used to control processes on a site. Dynamic runtimes are manipulated or operations are carried out on the server. An action does not generate any displayed data, but controls the process within the pipeline.
Possible output formats
XSP
A widespread possibility, already used in Cocoon 1.x, to develop Cocoon applications is the concept of the eXtensible Server Pages (XSP). An eXtensible server page is a normal and valid XML document. This contains i. d. Usually static content or certain functions that read dynamic content from a data source (database, hash table, file). In contrast to normal JavaServer Pages , the XSP file does not return an HTML, but an XML document that provides the content for further transformations. The XSP document is passed directly to the generator, which converts it into a server page. The functions contained in the XSP document are converted into Java code. In addition to the options already explained, the XSP page has an optional logic component. This often contains JavaScript (other programming languages are theoretically possible). The logic component is integrated directly into the XSP document and has the task of checking or further processing parameters transferred via POST request. All options are available that are available in JavaScript. If a logic component is integrated into the XSP document, the strict separation of logic, layout and content is lost. This problem can be solved by using so-called logic sheets; however, this is only useful when used in large projects. Another component that is used together with XSP is the eXtensible Transformer Language (XSLT). This has the task of further processing the XML data generated by the generator. The transformers already mentioned are used for this purpose. In order to control the sequence of the generator and transformer, the sitemap file must be adapted. This is where the real strengths of Cocoon come to the fore, as a very clear solution can be built by separating the logic and the layout, in which certain components can be replaced by others at any time. For example, it is possible to pass different XSP files to the generator of a pipeline, which changes the content of the web page but not the layout.
Control flow
By introducing the concept of flow control (control flow), a Cocoon developer has options that could previously only be used in a local application. Traditionally, web applications work via stateless HTTP, which means that a prompt response is generated to every request without saving the status of the web application or, if the request is made again, the program flow continues at the same point. An attempt is made to circumvent this fact with servlets by means of unique session IDs within cookies and URL rewriting. However, the program code is repeatedly run through from the beginning and branched into various functions on the basis of session IDs. This quickly becomes confusing and complicated, especially with larger applications. When working with forms and the values stored in them, problems arise especially when the user tries to navigate back one or more pages. Values entered there (transmitted with POST or GET) can often no longer be loaded. So that the developer can primarily take care of his application, the concept of continuations in connection with FlowScript was introduced with Cocoon 2.1.
FlowScript
FlowScript is based on the language JavaScript, which is widely used on the Internet . Since it is primarily intended to control the application process and not to integrate business logic into the Cocoon application, the restrictions compared to Java are no longer a problem. If complex processes and models are required, these can be imported into JavaScript in the form of Java classes.
Continuations
A common problem on the web is that the entries made on a website disappear without a trace when this page is reloaded. In Cocoon, this problem was completely solved by the concept of continuations. A continuation is created within the FlowScript. This is done automatically by calling cocoon.sendPageAndWait (). A continuation object has the task of storing the current state of the program, including the program Counter (the place in the FlowScript), all local variables and inputs by the user and the stack. The continuation object automatically receives a unique ID when it is created. After the continuation has been created, it is stored in a global hash table and can be reloaded if necessary. At this point in time the continuation object is still empty. After it has been stored in the hash table, the desired website is sent to the user. After executing the cocoon.sendPageAndWait () command, the FlowScript stops and waits for input from the user. Only then will the FlowScript continue. After the user has made his entries - for example in a form - he sends the entered data and requests the current continuation object stored in the hash table. This saves the values entered by the user in the web form. Only now has the continuation object been completely processed and can be reloaded at any time with the values entered by the user.
The use of continuations only makes sense if there is real interaction with the user.
The following flowchart in Figure summarizes the complete sequence of a continuation across all flow control components.
Cocoon Forms (Woody)
By far the most powerful form framework currently available in Cocoon is called Cocoon Forms (cForms). It offers a variety of options, e.g. B. Form checking, creation of pop-ups and simple integration of visual graphic elements. Forms is currently under development, so it is possible that certain elements will change. For example, Forms was developed under the code name Woody up to Cocoon Version 2.1.4. When switching to Cocoon version 2.1.5, the name and thus all library names and paths were changed. Forms will become the official standard framework for forms processing.
Structure of the Cocoon Forms
The concept of Forms, like almost everything in Cocoon, separates the content from the logic and the layout. For this reason, a form created with Forms consists of two files:
- Shape definitions
- Form templates
Form definitions describe the individual elements that are required in a form. A form definition file does not contain any presentation data. It can therefore be reused together with any number of presentation files. The elements in the shape definition file are called widgets. A large number of widgets are available to the developer, for example buttons, edit fields or combo boxes. Each of these widgets can be given an individual look, behavior and even functions. There are very complex possibilities to enable widgets to behave specifically, starting with the specification of the designation and description of an object, through the declaration of simple data types that a widget can accept, through to the execution of JavaScript code that is triggered by certain predefined events in the Widget is triggered.
In principle, form templates are XSL transformation files. They contain the presentation logic and bind the individual widgets. Not all widgets of a definition file have to be integrated. In addition, the shape template defines certain properties such as the size and color of each widget.
Forms processing
To create a website with forms, special forms transformers and a forms generator must be used. In addition, the whole concept must be controlled by FlowScript.
Web links
Individual evidence
- ↑ projects.apache.org . (accessed on April 8, 2020).
- ↑ cocoon.apache.org . (accessed on March 11, 2020).
- ^ Cocoon 3.0 Changes Report