Sylvain Wallez wrote:
>
> I am strongly -1 to resolve relative URIs relatively to the position of
> a component in the container hierarchy.
>
I totally agree here.
> IMO, we must keep the current behaviour. This allows all components to
> automatically adapt to the mount point of the current
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Unico Hommes wrote:
Carsten Ziegeler wrote:
Now, I think we can make it simpler :)
a) A sitemap component gets a Cocoon source resolver anyway.
We can provide in the setup() method a wrapper for
the Avalon SourceResolver that knows it's sitema
Carsten Ziegeler wrote:
Unico Hommes wrote:
Carsten Ziegeler wrote:
Now, I think we can make it simpler :)
a) A sitemap component gets a Cocoon source resolver anyway.
We can provide in the setup() method a wrapper for
the Avalon SourceResolver that knows it's sitemap. This
is simply an
Carsten Ziegeler wrote:
>
> ...
> >
> > Yes, but I think we should just either say that
> >
> > a) the service will not be able to resolve against the current
> > sitemap context, i.e. it will be relative to the root CM.
> > b) the service will not be one instance per container hierarchy
> > bu
Unico Hommes wrote:
> > > Hmm. But shouldn't *any* contextualizable component that lives in
> > > a hierarchical containment model *always* be contextualized
> > > against the container it was looked up on? Shouldn't that
> > > actually be part of the Contextualizable contract? I would say
> > > th
Carsten Ziegeler wrote:
>
> Unico Hommes wrote:
> >
> > Carsten Ziegeler wrote:
> > >
> > > Now, I think we can make it simpler :)
> > > a) A sitemap component gets a Cocoon source resolver anyway.
> > > We can provide in the setup() method a wrapper for
> > > the Avalon SourceResolver tha
Unico Hommes wrote:
>
> Carsten Ziegeler wrote:
> >
> > Now, I think we can make it simpler :)
> > a) A sitemap component gets a Cocoon source resolver anyway.
> > We can provide in the setup() method a wrapper for
> > the Avalon SourceResolver that knows it's sitemap. This
> > is simply an
Carsten Ziegeler wrote:
>
> Now, I think we can make it simpler :)
> a) A sitemap component gets a Cocoon source resolver anyway.
> We can provide in the setup() method a wrapper for
> the Avalon SourceResolver that knows it's sitemap. This
> is simply and doesn't need thread locals etc. a
Dean Cording wrote:
>
> The inability of a sitemap to resolve relative references outside
> of itself
> is the biggest bugbear I have with Cocoon. The ability the have
> a hierarchy
> of sitemaps allows me to modularise my applications very nicely but not
> being able to refer to a pipeline in ano
> Carsten Ziegeler wrote:
>
> >The recent discussions about migrating to fortress lead me
> >to think about our SourceResolver concept again.
> >
> >First the current state:
> >- The SourceResolver is an Avalon component that can be
> > looked up everywhere you have a component manager
> > (se
Sylvain Wallez wrote:
>
> Mmmh... what if a ThreadSafe component declared in cocoon.xconf expects
> an URI (a string) and then uses the Avalon resolver to get a Source?
> What base URI will be considered?
>
The cocoon context directory?
> I'm not sure we can avoid keeping the current base URI
hi,
what a wunderfull day, the idea to make it ThreadSafe sound very attractive
for me.
Perheaps it solves my Problems with the ParallelContentAggregator.
Christoph
"Carsten Ziegeler" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
news:[EMAIL PROTECTED]
> The recent discussions about migrating to f
Carsten Ziegeler wrote:
The recent discussions about migrating to fortress lead me
to think about our SourceResolver concept again.
First the current state:
- The SourceResolver is an Avalon component that can be
looked up everywhere you have a component manager
(service manager).
- The SourceR
The recent discussions about migrating to fortress lead me
to think about our SourceResolver concept again.
First the current state:
- The SourceResolver is an Avalon component that can be
looked up everywhere you have a component manager
(service manager).
- The SourceResolver resolves any U
14 matches
Mail list logo
