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
