cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Piroumian, Konstantin" <KPiroum...@flagship.ru>
Subject Re: [C2] Again context:// and SourceResolver
Date Thu, 06 Sep 2001 09:15:31 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message