On Mon, 2006-02-13 at 15:50 +0100, Andreas Hartmann wrote: > 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.
Right, I agree we have to do it the "/fallback"-URL way. > > > > 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 Ah, the second one is used for publication templating, right? Silly me... > > 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. It looks good, but as you say it may become obsolete one day, and it probably would mean a lot of work. Thanks for your comments/explanations. Josias > > > -- Andreas > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
