[extension to] DirectoryGenerator [...]
That's interesting. I guess, however, than that the best solution would be patching the real DirectoryGenerator (in doing so please sync the *TraversableGenerator in scratchpad too).
OK, but where should I post the patch?
Bugzilla (http://nagoya.apache.org/bugzilla) is your friend :-)
another question: I separated the real directory-scanner from the generator code. in what package should I put this helper-classes?
Either o.a.c.generation.helpers or o.a.c.components.something (if they are Avalon components, as I assume they should). But what is the need for that? Why would you use a directory scanner separately?
Besides, I think you'd much better use Source instead than File (see o.a.c.g.TraversableGenerator in scratchpad).
=======================
[...] PipelineDirectoryGenerator [...]
Delegating the inclusion to another pipeline looks pretty neat and definitely useful, but I don't feel like this should be the job of a monolithic generator. How about turning that part into a transformer who reads the DG/TG output and does exactly what you're planning?
I thougt of it, but this approach leads to the current design (I think): a special directory-scanner for XML files, a special directory-scanner for HTML files, a special directory-scanner for Image files
I can't see why. Is that because you have to generate (XML) metadata out of an image, as an example? In that case, it might make sense to have some kind of pluggable "scanners" that can be hooked into the generator in the component configuration phase. But that might also be overcomplicated.
Let's start from scratch: what you actually want is
1. dig through a set of directory, possibly disregarding the inclusion pattern in case of directories. This is just a simple patch to the current generator(s).
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 set of small interchangeable components instead than for the monolithic approach. Transformers still look best to me, with a possible variation: instean than chaining transformers you could configure a generic transformer with pluggable "renderers" which might respond to specific mime/type or pattern. Such as:
<map:transformer name="infoextractor src="...">
<renderer match="mime-type" pattern="text/html" class="..."/>
<renderer match="ext" pattern="gif|png|jpg" class="..."/>
</map:transformer>Where renderer is something like
interface XmlRenderer extends Reparameterizable {
Document render(Source src);
}Might be quite a bit of overcomponentization. OTOH, such renderers could be used elsewhere too (even outside Cocoon). I tend to like the multiple transformer best though, since they're more in line with Cocoon's overall design.
Ciao,
-- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
