cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alfred Fuchs <em...@alfred-fuchs.de>
Subject Re: DirectoryGenerator
Date Wed, 01 Oct 2003 14:29:50 GMT
 > Why would you use a directory scanner separately?
because I already had a directoryscanner
(with a callbackhandler and the default callbackhandler writes xml to stdout :-)
and the algorithm (based on java.io.File and java.io.FileFilter)
is completely independent of other packages.
the benefit of separating algorithm and "view" (output) is,
that I can use the scanner in a commandline util and
in the DirectoryGenerator as well.

> Besides, I think you'd much better use Source instead than File (see 
> o.a.c.g.TraversableGenerator in scratchpad).
You are right, I overlooked the scratchpad... I will adapt the generator.


> Is that because you have to generate (XML) metadata out of an image, 
 > as an example?
yes, and HTML, or f.e. a description (xml)-file (not necessary in the same directory),
with the same name as the file (f.e. MS-Word) itself.


 > 2. extract information from the returned resource in a pluggable and
 > extensible way (could be XPath or some binary manipulation).
 >
 > Have I got the overall picture? If that's the case, I'd still go for a
yes, nearly.
in my expamle I extract the title of a HTML page in this way:
if <title> exist and <title> not empty, use it as title.
otherwise use the first <h1> etc...
this is logic, simply done in a xslt, but hoe to do this in
a single xpath-query?


 > I tend to like the multiple transformer best though,
 > since they're more in line with Cocoon's overall design.
but why then the XPathDirectoryGenerator?
<map:generator type="directory" src="..."/>
<map:transformer src="Add-XInclude-Tags.xsl"/>
<map:transformer type="xinclude"/>
<map:transformer src="apply-xpath-to-included-files.xsl"/>
...
would do the same.
the "pipeline" approach seems very modualar to me
and reuses components, which already are there.

whats wrong with the "pipeline"-approach?
<map:aggregate/> also uses multiple pipes.


> <map:transformer name="infoextractor src="...">
>     <renderer match="mime-type" pattern="text/html" class="..."/>
>     <renderer match="ext" pattern="gif|png|jpg" class="..."/>
> </map:transformer>
hmmm,
would
      <renderer match="mime-type" pattern="text/html" class="...XSLT...">
	<source src="some-xslt.xsl"/>
      </renderer>

be OK?

best regards,
alfred



Mime
View raw message