cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <gian...@apache.org>
Subject Re: DirectoryGenerator
Date Wed, 01 Oct 2003 11:42:10 GMT
Alfred Fuchs wrote:
>>> [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/)


Mime
View raw message