cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: Context:// issue
Date Tue, 29 May 2001 07:53:58 GMT
> Giacomo Pati wrote:
>
> 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 :)
>
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 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.

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....


Carsten

Open Source Group                        sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de                          mailto: cziegeler@sundn.de
================================================================

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


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


Mime
View raw message