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] structurer location and resource types (was Re: [announcement] DOCO prototype in forrest and lenya rep)
Date Wed, 22 Mar 2006 11:06:16 GMT
Thorsten Scherler wrote:
> El mar, 21-03-2006 a las 10:53 +0100, Thorsten Scherler escribió:

...

> IMO this internal structurer definition do not belong into the {xdocs}
> dir. 
> 
> Resource types specific structurer have to be stored in a different
> folder then the xdocs dir as well. 
> 
> IMO it makes sense to move them out of the xdocs dir and have something
> like
> structurer/
> |-- internal 
> |-- resource-types
> `-- url

Can the location be defined in either a property or the locationmap? The 
user should be able to specify these locations.

Your suggestion is fine for the defaults though.

However, please, make this backward compatible. There are a number of 
sites using Views and it is becoming really difficult to keep track. 
Yes, I know it is in whiteboard, and that is the risk on takes, but 
deprecating rather than removing would be more appropriate in this stage 
of the dispatchers development I would think.

> To solve FOR-621 with http://forrest.apache.org/docs_0_80/cap.html is
> not enough. 
> 
> "SourceTypeAction assigns a "type" (a string) to an XML file. This is
> done based on information occuring in the header of the XML file, up to
> the document (root) element."
> 
> This solution works perfectly for xml files but there are so many
> non-xml files and formats that can mean a different source type and
> needs a different structurer. 
> 
> We need a counterpart of the SourceTypeAction for non-xml formats and
> keeping such information in meta data seems the most logical way. 
> 
> wdyt?

How are we to process non-XML formats in an XML publishing environment? 
Can you give an example of the kind of file you are thinking of 
processing in this way.

I ask because at present all non-xml files are simply read and served. 
It sounds to me like you have a way of improving on this, but I don't 
understand how.

Ross


Mime
View raw message