On Tue, 29 May 2001, Carsten Ziegeler wrote:
> > Giacomo Pati wrote:
> >
> > Quoting Donald Ball <[EMAIL PROTECTED]>:
> >
> > > 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 :)
> >
> Hm, I will not stop you from trying to do so, but I think it is nearly
> impossible without changing the result of the URLFactory.
> Currently it returns an URL which is not usable for that approach.
That's true. We'll have to subclass the returned URL from the URLFactory
and extend that URL with methods like setContentHandler or have other
methods for the URLFactory like
getURL(URL base, String location, XMLConsumer consumer)
but there is still the issue how it gets to a sitemap to handle
cocoon:// protocol.
> That is one of the reasons for the introduction of the SourceResolver
> , the URLResolver and the Source class where it is possible to
> handle those tasks.
> My thoughts were:
> - adding a method to the source object which generates sax events
> from the source and sends them to a specified XMLConsumer
> - adding logic to the FactoryURLResolver to handle the cocoon: context.
> The FactoryURLResolver sits between the SourceResolver and the
> URLFactory and has access to the current sitemap handler. So it
> should be possible that this object can resolve the cocoon:
> urls.
Would extending the URLFactory interface like above solve it?
>
> So this would mean that the cocoon: urls are handled by a
> combination of the Source and the FactoryURLResolver class but
> not by the URLFactory.
>
> But these are only vague thoughts for an implementation.
>
> The easiest solution is of course to forget about the performance
> (for a first version). The cocoon: url would then generate
> a real url which is resolved by a byte stream and this byte
> stream is reparsed. Easy implementation - bad performance....
Forget that last proposal :(
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
