forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: xml output plugin and filename extension .xml
Date Mon, 16 Jan 2006 11:52:49 GMT
David Crossley wrote:
> Ross Gardler wrote:
>>David Crossley wrote:
>>>I have a partially working output plugin to generate a
>>>plain xml document type solely to be consumed by Anakia. [1]
>>>They can it "xdoc".
>>>However, i have an issue at the moment. Can you help?
>>>I want the output to be .xml filename extension, but of
>>>course Forrest uses that for its internal format. I suppose
>>>that later Forrest will use .xhtml2 but not now or maybe
>>>not even use a filename extension..
>>>So i am using .xdoc
>>>localhost:8888/index.xdoc works now.
>>>Is there a way to reclaim the xml filename extension?
>>How about we change the internal format extension to ".forrest"
> Okay.
>>I see no reason why it should be ".xml", in fact having it as ".xml" has 
>>forced us to use ".source.xml" for the original source. Which is counter 
> Would that be any different.

Internally, no. But externally we could map *.xml to *.source.xml via 
the locationmap, so the user would not need to worry about *.source.xml.

In use cases like this one, the locationmap would map *.xml to something 
like *.anakia.xml.

>>There is a backward compatability issue here though. If people are using 
>>the *.xml urls for some reason (like one of my sites does) they will 
>>need to rewrite client applications that retrieve those URLs. We could 
>>provide an internal plugin that keeps backward compatability and 
>>deprecate it (schedule for removal in the 1.0 release).
> Do you have some clues about doing that?

(warning the below is my thought dump - I've not fully considered the 
implications or the completeness of the approach)

All references to cocoon://*.xml would need to become 
cocoon://*.forrest. All matchers for *.xml would need to become 
*.forrest (in both core and plugins).

The internal backward campatability plugin would need a copy of all core 
sitemaps that were touched in the above edits.

We would need to keep the sitemaps in the backward compatability plugin 
in synch with the core plugins, it would therefore be wise to remove all 
matches that are not touched in the edits.

> Sounds big. I don't have the energy for it
> at the moment. So i think that i will go with
> the .xdoc extension for this first version
> of the plugin.

If my ideas above are correct it is not that big, just some careful 
search and replace. It is bigger than writing a script to rename the 
files once produced though.

> If someone else can manage to coordinate Ross'
> suggestion, then please do.

Probably worth puttin gthis in Jira - it would be usefu to do.


View raw message