cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: Context:// issue
Date Tue, 29 May 2001 07:34:16 GMT
Quoting Donald Ball <balld@webslingerZ.com>:

> On Tue, 29 May 2001, giacomo wrote:
> 
> > > > The context and resource protocols should match the semantics for
> > > > file and jar:
> > > >
> > > > context://relative/path/from/context/root
> > > > resource://path/to/packaged/resource
> > >
> > > why don't we go ahead and enumerate all of the extra protocols
> recognized
> > > by c2 and their semantics, and stick them in a document for
> reference.
> > > i'll take a stab:
> > >
> > > context urls point to xml resource pipelines relative to the root of
> the
> > > current sitemap. the same context url in two seperate sitemaps can
> resolve
> > > to two seperate pipelines. format: context://{path}
> >
> > The context protocol point into the file system and not to resource
> > pipeline. But yes, the same context url in two seperate sitemaps can
> > resolve to two seperate files. format: context://{path}
> 
> and it's always relative to the location of the current sitemap's map
> file?

Sorry, yes, it's how it should be but am not sure if the implementation respects 
this (IIRC it always resolves to the root of the servlet context). The early 
design decision was that the EntityResolver represented by the Environment 
object should take care of this but recent changes has deluted that approach. 
That's why the Environment interface has methods like setPrefix etc. to make it 
able to resolve correctly in case of sub sitemap mounts. I'm unsettle if 
I should fighting for old design decision because I don't remember exactly why 
this or that decision has been taken and it can truly be that I'm wrong today, 
so, do what you think is correct here.

> > > cocoon urls point to xml resource pipelines relative to the root of
> the
> > > current webapp. the same cocoon url in two seperate sitemaps always
> > > resolves to the same resource pipeline. format: cocoon://{path}.
> >
> > Not sure here. As your first isn't how you thought which one is
> relative
> > to the current sitemap and wich one is not. As this protocol is not
> > implemented yet we can model it in the way we like it.
> 
> what is it's intended purpose then? if it's _not_ what i've described,
> i think we need to add something to do what i've described - maybe the
> webapp:// protocol?

The main problem is that all custom protocol served by the URLFactory so far 
resolve into a byte stream but the special cocoon:// protocol should resolve 
into a SAX stream for performance reasons. If you find a common interface for 
the URLFactory which combines both worlds your a real smart guy :)

Giacomo

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message