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
