cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From da...@cocoon.zones.apache.org
Subject [DAISY] Updated: Creating a Generator
Date Tue, 06 Sep 2005 18:16:02 GMT
A document has been updated:

http://cocoon.zones.apache.org/daisy/documentation/688.html

Document ID: 688
Branch: main
Language: default
Name: Creating a Generator (unchanged)
Document Type: Document (unchanged)
Updated on: 9/6/05 6:15:46 PM
Updated by: Berin Loritsch

A new version has been created, state: publish

Parts
=====
Content
-------
This part has been updated.
Mime type: text/xml (unchanged)
File name:  (unchanged)
Size: 3565 bytes (previous version: 1361 bytes)
Content diff:
(3 equal lines skipped)
    <h1>Creating a Generator</h1>
    
    <p>One of the most common types of components to create in Cocoon is to create a
--- Generator.  Whether you realize it or not, every time you write an XSP page, you
--- are creating a Generator.  XSP pages do a number of things for you, but there is
--- a considerable amount of overhead involved with compiling and debugging.  After
+++ Generator. Whether you realize it or not, every time you write an XSP page, you
+++ are creating a Generator. XSP pages do a number of things for you, but there is
+++ a considerable amount of overhead involved with compiling and debugging. After
    all, when your XSP page isn't rendering like you expect and the XML is
--- well-formed, where do you turn?  You can examine the Java code that is generated
--- from the XSP, but that can have its own set of challenges.  I had a perfectly
+++ well-formed, where do you turn? You can examine the Java code that is generated
+++ from the XSP, but that can have its own set of challenges. I had a perfectly
    valid Java source file generated for Java 5's javac program, but it wouldn't
--- compile in Cocoon.  Why?  The default compiler included with Cocoon doesn't
+++ compile in Cocoon. Why? The default compiler included with Cocoon doesn't
    support Java 5.</p>
    
    <p>Sometimes our needs are so simple and so narrowly defined that it would be
    much easier for us to create our Generator right in our own IDE using all of the
--- creature features that are included.  Eclipse and IDEA are both wonderfully rich
--- environments to develop Java code.  Generators are much simpler beasts than your
+++ creature features that are included. Eclipse and IDEA are both wonderfully rich
+++ environments to develop Java code. Generators are much simpler beasts than your
    transformers and your serializers, so it makes creating them directly even more
--- enticing.  Cocoon does have some wonderful generators like the
+++ enticing. Cocoon does have some wonderful generators like the
    JXTemplateGenerator and others, but we are going to delve into the world of
    creating our own.</p>
    
+++ <h2>How the Sitemap Treats a Generator</h2>
+++ 
+++ <p>In the eyes of the Sitemap, all XML pipelines start with the Generator.  By
+++ definition, a Generator is the first <a href="daisy:689">XMLProducer</a> in
the
+++ pipeline.  It is the source of all SAX events that the pipeline handles.  It is
+++ also a <a href="daisy:673">SitemapModelComponent</a>, so it must follow those
+++ contracts as well.  Lastly, it can be a
+++ <a href="daisy:675">CacheableProcessingComponent</a> satisfying those contracts
+++ as well.  As usual, the order of contracts honored starts with the
+++ SitemapModelComponent, then the CacheableProcessingComponent contracts, and
+++ lastly the XMLProducer contracts.  If the results of the Generator can be
+++ cached, Cocoon will attempt use the cache and bypass the Generator altogether if
+++ possible.  The Caching mechanism can take the place of the Generator because it
+++ can recreate a SAX stream on demand as an XMLProducer.</p>
+++ 
+++ <p>In the big scheme of things, the Sitemap will <tt>setup()</tt> the
Generator,
+++ and then assemble the XML pipeline.  After Cocoon assembles the pipeline,
+++ chaining all XMLProducers to XMLConsumers (remember that an XMLPipe is both),
+++ Cocoon will call the <tt>generate()</tt> method on the Generator.  That is
the
+++ signal to start producing results, so send out the SAX events and have fun.</p>
+++ 
+++ <h2>Building our Own Generator</h2>
+++ 
+++ <p>We are going to keep things easy for our generator.  As usual, we will make
+++ the results cacheable because that is just good policy.  In the spirit of trying
+++ to be useful, as well as trying to keep things manageably simple, let's create a
+++ BeanSerializer.  The XML generated will be very simple, utilizing the JavaBean
+++ contracts and creating an element for each property, and embedding the value of
+++ the property within that element.  There won't be any attributes, and the
+++ namespace will match the the JavaBean's fully qualified class name.  If a
+++ property has something other than a primitive type, a String or an equivalent
+++ (like Integer and Boolean) as its value, that object will be treated as a Bean.
+++ </p>
+++ 
+++ <p>To realize these requirements we have to find a bean, and then "render it". 
+++ In this case the XML rendering of the bean will be recursive.</p>
+++ 
    </body>
    </html>


Fields
======
no changes

Links
=====
no changes

Custom Fields
=============
no changes

Collections
===========
no changes

Mime
View raw message