Ugo Cei wrote:
> A long long time ago ... [1] someone here or on cocoon-users made a
> good job of explaining the pros & cons of Sources vs. Generators.
> Unfortunately, I can't find it again either on MARC, via Google or in
> my archived folders.
>
> If the original author or someone else can give me a pointer, I'd be
> forever grateful :)
Couldn't find the post you mention, as searching "source generator" give
so many replies ! Anyway, here are some (hopefully clear) explanations.
-- o --
A source is a mean to access data, and makes no assumption on what kind
of data it is. It provides the low-level plumbing to access the data.
That's why we have FileSource, URLSource, BlobSource (for SQL blobs),
SlideSource (for webdav), etc. There is absolutely no assumption that
data accessed using a Source is XML, nor that it can be converted to XML
(e.g. gif images).
Sources were added to Cocoon, and later to Avalon because the URL
protocol extension mechanism provided by the JDK is very limited, as it
requires some parameters to be set at the JVM level and only allows
JVM-wide protocol definitions, which is obviously bad for application
servers.
-- o --
On the other side, a generator produces XML from a given environment. We
have some generators that rely on sources, other that don't. The
RequestGenerator for example produces some XML, but doesn't rely on a
Source.
Source-related generators take a Source as input and generate XML from
the data given this Source. The most well-kown is the FileGenerator,
which feeds an XML parser with the Source data. This makes the important
assumption that data is an XML text. But there are also other
source-related generators that accept non-XML data : the SWFGenerator
reads a Flash document from a source and converts it to XML.
So a source-related generator should be considered as a parser (in the
general meaning of the word), that takes data from a source and produces
XML.
-- o --
Now that things are clear, lets add some confusion ;)
Some sources provide access to native XML datasources, such as xmldb.
For these sources, there is no need for a parser since the data can
already been accessed in its XML form (i.e. DOM or SAX). Moreover, it
would be a waste of time to ask the source to serialize XML data to
textual form and then feed a parser. So these Sources implement the
XMLizable interface to provide direct access to XML data.
Cocoon's SourceResolver takes care of that and provides a toSAX(Source)
method that decides to use a parser or not depending on the XMLizable
nature of the Source. Of course, if the source isn't natively XML, this
assumes it provides XML in its textual form.
-- o --
As a final note, Sources have a wider usage range than geneators. Cocoon
uses sources everywhere it needs to access data, since sources provide
independence against the access means. So sources are used to read XSL
stylesheets, the sitemap, XSP source files, images (in readers), etc.
And don't forget the nice Cocoon source that gives access to data
produced dynamically by Cocoon itself.
Hope this helps.
Seems like this explanation is a good candidate for an xdoc. Where
should it be better located : in user concepts, or developper concepts ?
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
