cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: DirectoryGenerator source-oriented refactoring
Date Thu, 10 Jul 2003 10:32:55 GMT
Gianugo Rabellino wrote:

> Sylvain Wallez wrote:
>
>>> I just added to scratchpad a refactored implementation of 
>>> DirectoryGenerator (TraversableGenerator) that doesn't work with 
>>> just files but with any TraversableSource. Together with it, a 
>>> refactoring was done on XPathDirectory, which is now 
>>> XPathTraversable, so that even XPath queries can be done on any 
>>> TraversableSource (while we were at it, we added namespace support, 
>>> missing on the previous implementation). 
>>
>>
>> Damn, competing implementations : I've had this same thing on my HD 
>> for several weeks now as part of the new version of the CVSSource. 
>> Shame on me, I should have committed this for a long time. "release 
>> early, release often".
>
>
> Oh well... silly me for not asking. :-)
>
>> My version is cacheable, but doesn't support XPath. I'll look at 
>> yours to see how to merge them.
>
>
> Ours is cacheable too, actually it was very little more than 
> s/File/Source on the cacheable DirectoryGenerator, so a more clever 
> implementation would be most welcome. :-) Also, the XPath stuff is on 
> an different class (XPathTraversableGenerator), which extends 
> TraversableGenerator, so some care should be taken in merging the two. 


My cache implementation deals with SourceValidity instead of 
lastModified(), which allows caching for sources where lastModified 
isn't available (e.g. a CVS directory, or a tagged CVS source which can 
go back in time if the tag is moved). Also, I added a "directories-only" 
parameter which automatically filters regular files (it can be 
needlessly expensive to get infos on them and later discard them in the 
pipeline).

But my implementation started from the 2.0 DirectoryGenerator which 
hasn't all the fancy sort stuff. So I think a merge is actually what's 
needed.

And while we're at refactoring, what do you think of having separate 
regexps for directories and files ? This would be really useful since 
their respective naming rules are totally different. E.g. if I want only 
.xml files, the regexp has to be "^[^.]*$|\.xml$", which looks quite 
ugly when the file regexp would simply be "\.xml$".

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message