Josias Thoeny wrote:
[...]
Or would the following solution be better:
If a requested RNG (or XSL) file contains an include using the
fallback:// protocol, resolve the URI and replace it by the actual URL
before sending the file to the client, instead of letting the client
request /fallback uris?
What would the "actual" URL look like? Fallback URLs are usually
resolved to internal URLs, which can't be accessed by the client.
By using /fallback URLs, we avoid the need for mapping fallback://
URLs HTTP-accessible URLs.
BTW, what is the "/lenya" for in fallback://lenya/something ?
Is it really necessary?
It's used to separate core resources from publication resources:
fallback://lenya/xslt/ -> core XSLTs
fallback://xslt -> publication XSLTs
Maybe we should change the deployment directory structure:
/webapp
/core
/modules
/pubs
and use e.g.
fallback://core/xslt/...
Actually IMO this should be obsolete someday because the "core" should
be just a set of modules.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
