forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: [RT] plugin infrastructure
Date Wed, 03 Nov 2004 20:59:38 GMT


Sean Wheller wrote:
> On Wednesday 03 November 2004 19:59, Ross Gardler wrote:
> 
>>I spoke too soon. There is a problem with source format plugins that
>>came to light today. See http://issues.cocoondev.org/browse/FOR-348 for
>>details, at this time I see no easy solution - there are a couple of
>>suggestions in that bug report, but I'm not too happy with any of them.
>>
>>If we can solve this problem all the rest of my suggestions in this
>>thread still work.
> 
> 
> Sorry I've been so quiet. Been hard at work.

That's the way it goes, we know you'll do what you can when you can.

> 
> Ross, could SourceTypeAction not work. If the source type is not matched, then 
> pass to next sitemap.xmap with the map:otherwise.

It already uses SourceTypeAction.

The problem is that you can't do a <map:otherwise> that appears in 
another sitemap.

It seems to me that Cocoon decides that a matcher has done its work 
whenever a file is generated using <map:generate...>, in order to do a 
SourceTypeAction you have to generate the file first hence Cocoon marks 
the request as having been processed.

This assumption is based on the fact that the match for **.xml in the 
OpenOffice.org plugin works fine, but this only does a <map:generate...> 
whenever the relevant *.sxw or *.sxi exist, under these circumstances 
the match has done its job. If the sci/sxw files don't exist (i.e. the 
source file is really a *.xml file) then the <map:generate...>is never 
reached and so the subsequent matchers are used.

Hmmmm... I wonder if actions are our solution though... I'm off to the 
cocoon docs.

Ross

Mime
View raw message