Oops, wrong list. It was for cocoon-dev. > > Hi, C2ers! > > > > I'm still trying to understand how source resolver works with different > > types of paths and protocols. > > > > Can anybody please point me to some kind of documentation about the path > > resolution? I can't figure out why SourceResolver.resolve() returns > > different formats of paths. Is that expected behavior? Reading the mail > > archive did not give a clue of what "context" protocol supposed to be. E.g., > > see this posting from Berin: > > http://mailman.real-time.com/pipermail/cocoon-devel/2001-May/008073.html . > > > > I expect, that every path in a sitemap must be resolved relatively to > > servlet context and in this case using an absolute path like > > '/docs/index.xml' will be equal to 'context://docs/index.xml'. I think that > > the following behavior is more obvious to end-users: > > > > /path/file.xml --> points to a file from the webapp context root > > path/file.xml --> ponts to a file relative to the current request path > > This sounds very appealing and reasonable to me. > > > and there is no need for a context:// protocol in this case. As I remember, > > there was a proposal for 'sitemap://' protocol, which can be used in > > sub-sitemaps, which could be used for sitemap-relative paths. > > > > Do I get something wrong? Any comments/suggestions? > > I have had a short look into the sitemap:// protocol. I think > it would be extremely useful (to have at least such a functionality). > When using subsitemaps (as we heavily do) it's the only way to keep > your site quite modular. > > I'm not quite sure if we would need a new SourceFactory or an URLFactory > for this? Problem is: AFAIK we need the current request to get path of > the subsitemap. I suspect that something like all this is already implemented (context://, context:///, etc.), but in my opinion, the current path resolution needs documenting and refining, because it's rather hard to understand, even looking to the source code doesn't help. > > How would you like to implement your proposed way of URL handling? I will wait for more opinions from cocoon team. > -- > Torsten > Konstantin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
