> Giacomo Pati wrote:
>
> 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?
Not necessarily. The question is: What do we want (today)? Do we want
(only) a working cocoon: url or do we really want a URL object for those
urls?
For the first (simple) solution, the URLFactory could be as it is and
the cocoon: url is not handled by the URLFactory but by the
FactoryURLResolver.
This FactoryURLResolver looks if the url starts with cocoon:. If so it
handles it by itself, otherwise the url is passed on to the URLFactory.
If you want the (more sophisticated) solution - a real URL object -
you are right.
For now, I think, the simple solution is enough (for C2.1).
>
> >
> > 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 :(
Ok, ok, just kidding...
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: [EMAIL PROTECTED]
================================================================
>
> Giacomo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
