A document has been updated:
http://cocoon.zones.apache.org/daisy/documentation/681.html
Document ID: 681
Branch: main
Language: default
Name: Creating a Reader (unchanged)
Document Type: Document (unchanged)
Updated on: 8/25/05 6:02:21 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: 5976 bytes (previous version: 5967 bytes)
Content diff:
(3 equal lines skipped)
<h1>Creating a Reader</h1>
<p>Readers are the components that send you a stream without the XML
processing
--- that normally happens in a pipeline. Cocoon already comes with some
readers out
+++ that normally happens in a pipeline. Cocoon already comes with some readers
out
of the box such as your FileReader which serializes files from your webapp
--- context. What if you need something that doesn't come from the file
system?
--- What if you need to create content on the fly but the XML processing gets
in the
--- way? That's where the Reader comes to play. Even though there is a
--- DatabaseReader in the Cocoon's SQL block, we are going to go through the
process
--- of creating a cacheable database reader here.</p>
+++ context. What if you need something that doesn't come from the file system?
What
+++ if you need to create content on the fly but the XML processing gets in the
way?
+++ That's where the Reader comes to play. Even though there is a
DatabaseReader in
+++ the Cocoon's SQL block, we are going to go through the process of creating a
+++ cacheable database reader here.</p>
<p>In the sitemap we use the reader we are going to develop like this:</p>
(3 equal lines skipped)
</pre>
<p>The sitemap snippet above matches anything in the attachment path
followed by
--- the ID for the attachment. It then passes the ID into the <tt>src</tt>
--- attribute for our reader. Why not include the nice neat little extension
for
--- the file after the ID? We actually have a very good reason: Microsoft. If
you
--- recall from the <a href="daisy:674">SitemapOutputComponent Contracts</a>
page,
--- Internet Explorer likes to pretend its smarter than you are. If you have a
file
--- extension on the URL that IE knows, it will ignore your mime-type settings
that
--- you provide. However, if you don't provide any clues then IE has to fall
back
--- to respecting the standard.</p>
+++ the ID for the attachment. It then passes the ID into the <tt>src</tt>
+++ attribute for our reader. Why not include the nice neat little extension
for the
+++ file after the ID? We actually have a very good reason: Microsoft. If you
recall
+++ from the <a href="daisy:674">SitemapOutputComponent Contracts</a> page,
Internet
+++ Explorer likes to pretend its smarter than you are. If you have a file
extension
+++ on the URL that IE knows, it will ignore your mime-type settings that you
+++ provide. However, if you don't provide any clues then IE has to fall back to
+++ respecting the standard.</p>
<h2>How Does the Sitemap Treat a Reader?</h2>
--- <p>A Sitemap fills two of the core contracts with the Sitemap. It is both a
--- SitemapModelComponent and a SitemapOutputComponent. You <em>can</em> make
it a
+++ <p>A Sitemap fills two of the core contracts with the Sitemap. It is both a
+++ SitemapModelComponent and a SitemapOutputComponent. You <em>can</em> make
it a
CacheableProcessingComponent as well, which will help reduce the load on
your
--- database by avoiding the need to retrieve your attachments all the time. In
+++ database by avoiding the need to retrieve your attachments all the time. In
fact, unless you have a good reason not to, you should always make your
--- components cacheable just for the flexibility in deployment later. I
recommend
+++ components cacheable just for the flexibility in deployment later. I
recommend
you read the articles on the core contracts to understand where to find the
resources you need.</p>
--- <p>A sitemap will fulfill all its core contracts first. It will then query
the
--- reader using the <tt>getLastModified()</tt> method. The results of that
method
+++ <p>A sitemap will fulfill all its core contracts first. It will then query
the
+++ reader using the <tt>getLastModified()</tt> method. The results of that
method
will be added to the response header for browser caching purposes--although
it
--- is only done for the CachingPipeline. Lastly, the sitemap will call the
--- <tt>generate()</tt> method to create and send the results back to the
client.
+++ is only done for the CachingPipeline. Lastly, the sitemap will call the
+++ <tt>generate()</tt> method to create and send the results back to the
client.
It's a one stop shop, and because the Reader is both a
SitemapModelComponent and
a SitemapOutputComponent it is the beginning and the end of your
pipeline.</p>
(3 equal lines skipped)
<h2>ServiceableReader: A Good Start</h2>
<p>The ServiceableReader provides a good basis for building our database
bound
--- AttachmentReader. The ServiceableReader implements the Recyclable,
LogEnabled
+++ AttachmentReader. The ServiceableReader implements the Recyclable,
LogEnabled
and Serviceable interfaces and captures some of the information you will
need
--- for you. We will need these three interfaces to get a reference to the
--- DataSourceComponent, our Logger, and to clean up our request based
artifacts.
+++ for you. We will need these three interfaces to get a reference to the
+++ DataSourceComponent, our Logger, and to clean up our request based
artifacts.
You might want to implement the Parameterizable or Configurable interfaces
if
you want to decide which particular database we will be hitting in your own
--- code. For now, we are going to hard code the information.</p>
+++ code. For now, we are going to hard code the information.</p>
<h3>The Skeleton</h3>
(30 equal lines skipped)
// ... skip many methods covered later
public void setup( SourceResolver sourceResolver, Map model, String
src, Parameters params )
--- throws IOException, ProcessingException, SAXException
+++ throws IOException, ProcessingException, SAXException
{
// ... skip setup code for now
}
(5 equal lines skipped)
}
</pre>
--- <p>If you'll notice we added the Disposable interface to the contract as
well.
+++ <p>If you'll notice we added the Disposable interface to the contract as
well.
This is so that we can be good citizens and release our components when we
are
--- done with them. Anything pooled needs to be released. While it's probably
safe
--- to treat your DataSourceComponent and your ServiceManager as singletons in
the
--- system, we still want to be responsible. First things first, let's get our
--- DataSourceComponent and hold on to it as long as this Reader is around. To
do
--- this we will need to add two more class fields:</p>
+++ done with them. Anything pooled needs to be released.</p>
+++ <h3>Getting a Reference to Our DataSourceComponent</h3>
+++
+++ <p>While it's probably safe to treat your DataSourceComponent and your
+++ ServiceManager as singletons in the system, we still want to be responsible.
+++ First things first, let's get our DataSourceComponent and hold on to it as
long
+++ as this Reader is around. To do this we will need to add two more class
fields:
+++ </p>
+++
<pre> private DataSourceComponent datasource;
private ServiceSelector dbselector;
</pre>
(6 equal lines skipped)
Fields
======
no changes
Links
=====
no changes
Custom Fields
=============
no changes
Collections
===========
no changes
