cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierpaolo Fumagalli <>
Subject Re: extensions in public URIs [was: RE: Variations on a theme by Cocoon]
Date Wed, 16 Feb 2000 08:20:06 GMT
Niclas Hedhman wrote:
> his
> <process uri="/docs/*.html" source="/some/other/place/*.xml">
> makes it looks like a extension matching. But it is not.
> If one chooses to use the W3C recommendation (or whatever it is), one could
> just use...
> <process uri="/docs/*" source="/some/other/place/*.xml">
> ...instead.
> Cocoon is thereby providing a lot more power to the Webmaster to be able to
> maintain the URIs over time, no matter what happens to the content location,
> format or generation methods.

Totally correct... or even

<process uri="docs/*.xyz" source="some/other/place/*.xml">

The thing to understand, really, is that "docs/*.xyz" do not exist
anywhere on the disk, and they're not supposed to, of course outside the
context of the cache... While "some/other/place/*.xml" must exist on the
local disk, and, even if someone requests something like
"some/other/place/index.xml" and that file IS on the disk, Cocoon will
reply with a 404 (NOT FOUND), because we don't have a rule for defining
it in the target uri space (it's not mounted...)...
To serve it, I would have to specify a sitemap rule like

<resource uri="some/other/place/*.xml" source="some/other/place/*.xml"/>

Also, I use extension in my example because they let me remember what is
the final content type served... I'll try to avoid their use in the


-          P              I              E              R          -
stable structure erected over water to allow the docking of seacraft
<>    <>
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <> --------------------

View raw message