And to add more complexity, we have a XMLizer! What's that? Now, as Sylvain explains a Source delivers data in any format which might not be XML. To classify the format of the data, mime-types are used, so a Source can return the mime-type of the data, for example "text/html" etc.
The XMLizer is a (guess what) configurable Avalon component which knows how to convert some mime-types to XML, for example it can convert "text/html" to XHTML (using jtidy). The Cocoon SourceResolver checks (as Sylvain has explained) in the toSAX(Source) method, if the Source is itself XMLizable, which means if the Source can convert itself (or it's data) to an XML representation). If this is not the case, the XMLizer is used. It get's the mime-type from the source and looks if it has a mapping for this mime-type to XML. If so this mapping is used. If the source does not return a mime-type, it's assumed that the source already delivers XML and the XML parser is used on the content. So, if you look at this scenario, there is actually no need for special generators like the SWFGenerator mentioned below, because the XMLizer could be extended by this conversion and then the usual FileGenerator could be used as well. And now the final attack: Nearly all generators could be rewritten as sources, for example the RequestGenerator could be written as a "request:" protocol. But does this make sense - I would say: "No". I think a protocol makes sense if several, different sources (documents, pieces of information) can be obtained using this protocol. For example using an FTP protocol you can fetch several files from the FTP server. A request protocol for example addresses only one piece of information, the request. Ok, can someone add more "confusion"? ;) And yes, Sylvain, this should really go in the docs! Carsten > -----Original Message----- > From: Sylvain Wallez [mailto:[EMAIL PROTECTED]] > Sent: Thursday, July 04, 2002 10:03 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: Source vs. Generator > > > 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]
