Geoff Howard wrote:
Sylvain Wallez wrote:
Geoff Howard wrote:
Sylvain Wallez wrote:
Unico Hommes wrote:
BTW, Unico, I don't know what is your mail software, but it
doesn't send the "In-Reply-To" header, which breaks thread views
in Mozilla and makes following discussions highly difficult.
Sylvain Wallez wrote:
Actually, Unico is not the only one. What I've found is that Mozilla
uses the In-Reply-To header whereas Outlook (at least some version) uses
"Thread-Topic" and "Thread-Index".
Outlook's headers seem strange to me, as I don't know how a mailer can
rebuild a thread tree wit
Carsten Ziegeler wrote:
Unico Hommes wrote:
I haven't had doubts that hosting nodes as components in an IoC
container is a good approach, I think it makes perfect sense in light of
a sitemap's inheritable nature. What I *have* been having doubts about
is the way the container is now being confi
n-Reply-to"
JD
-Original Message-
From: Unico Hommes [mailto:[EMAIL PROTECTED]
Sent: 2004-01-30 10:06 AM
To: [EMAIL PROTECTED]
Subject: RE: Mail thread headers (was Re: source resolving in 2.2)
Sylvain Wallez wrote:
>
> Geoff Howard wrote:
>
> > Sylvain Wallez
JD Daniels wrote:
>
> Outlook 2000 *does*
>
> I was getting frustrated I was not getting any replies to a
> post i made... I was lazy and just hit reply to an existing
> message to get the address and wiped out the original text.
> This thread made me look.. and it does send "in-Reply-to"
>
-
From: Unico Hommes [mailto:[EMAIL PROTECTED]
Sent: 2004-01-30 10:06 AM
To: [EMAIL PROTECTED]
Subject: RE: Mail thread headers (was Re: source resolving in 2.2)
Sylvain Wallez wrote:
>
> Geoff Howard wrote:
>
> > Sylvain Wallez wrote:
> >
> >> Unico Hommes wrote:
Sylvain Wallez wrote:
>
> Geoff Howard wrote:
>
> > Sylvain Wallez wrote:
> >
> >> Unico Hommes wrote:
> >
>
>
> BTW, Unico, I don't know what is your mail software, but
> it doesn't
> send the "In-Reply-To" header, which breaks thread views
> in Mozilla
> and makes follow
Sylvain Wallez wrote:
Geoff Howard wrote:
Sylvain Wallez wrote:
Unico Hommes wrote:
BTW, Unico, I don't know what is your mail software, but it doesn't
send the "In-Reply-To" header, which breaks thread views in Mozilla
and makes following discussions highly difficult.
I use Outlook. I ch
Geoff Howard wrote:
Sylvain Wallez wrote:
Unico Hommes wrote:
BTW, Unico, I don't know what is your mail software, but it doesn't
send the "In-Reply-To" header, which breaks thread views in Mozilla
and makes following discussions highly difficult.
I use Outlook. I checked the thread view
Sylvain Wallez wrote:
Unico Hommes wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
As for the redirector, please add it to InvokeContext. This makes it
available to both ActNode and CallFunctionNode. This is really a
private concern of the Processor that has no need to spread somewhere
Unico Hommes wrote:
I'd already replied to Sylvain's mail yesterday but it never seems to
have shown up :-/
Carsten Ziegeler wrote:
Do you mean the Processor is made available into the Avalon Context object in order for processing nodes to access it? A side effect is that it also makes it acces
Unico Hommes wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
As for the redirector, please add it to InvokeContext. This
makes it available to both ActNode and CallFunctionNode. This
is really a private concern of the Processor that has no need
to spread somewhere else.
What about
Unico Hommes wrote:
>
> I haven't had doubts that hosting nodes as components in an IoC
> container is a good approach, I think it makes perfect sense in light of
> a sitemap's inheritable nature. What I *have* been having doubts about
> is the way the container is now being configured from a site
Carsten Ziegeler wrote:
>
> Unico Hommes wrote:
> >
> > I haven't thought it all the way through either but I see some
> > complexity arising now.
> >
> > For instance in a subsitemap the components container must inherit
> > from the supersitemaps components container. But the
> subsitemaps
Unico Hommes wrote:
>
> I haven't thought it all the way through either but I see some
> complexity arising now.
>
> For instance in a subsitemap the components container must inherit from
> the supersitemaps components container. But the subsitemaps node
> container needs to inherit from both t
Carsten Ziegeler wrote:
>
> Unico Hommes wrote:
> >
> > > >
> > > Yes, that's true as well - sigh. I thought this context is only
> > > available to tree processor components, but it seems that you're
> > > right and this context is passed down to all components.
> > >
> >
> > The same goes for
Unico Hommes wrote:
>
> > >
> > Yes, that's true as well - sigh. I thought this context is
> > only available to tree processor components, but it seems
> > that you're right and this context is passed down to all components.
> >
>
> The same goes for the ServiceManager. It currently exposes all
>
Sylvain Wallez wrote:
>
> Carsten Ziegeler wrote:
>
>
> As for the redirector, please add it to InvokeContext. This
> makes it available to both ActNode and CallFunctionNode. This
> is really a private concern of the Processor that has no need
> to spread somewhere else.
What about the flow
I'd already replied to Sylvain's mail yesterday but it never seems to
have shown up :-/
Carsten Ziegeler wrote:
>
> > Do you mean the Processor is made available into the Avalon Context
> > object in order for processing nodes to access it? A side effect is
> > that it also makes it accessible
Sylvain Wallez wrote:
>
> Wait, wait, wait...
>
Too late... :) (Just kidding)
> Do you mean the Processor is made available into the Avalon Context
> object in order for processing nodes to access it? A side effect is that
> it also makes it accessible to all components defined in the sitemap,
Carsten Ziegeler wrote:
Unico Hommes wrote:
Ah, ok, so what do you think of using that then?
I just noticed that the key for the processor is just
"treeprocessor", what do you think of using a more qualified
name like org.apache.cocoon.Processor or the name of the
implementation?
Yes, th
Unico Hommes wrote:
> > Ah, ok, so what do you think of using that then?
> > I just noticed that the key for the processor is just
> > "treeprocessor", what do you think of using a more qualified
> > name like org.apache.cocoon.Processor or the name of the
> > implementation?
> >
>
> Yes, that was
Carsten Ziegeler wrote:
>
> Unico Hommes wrote:
> >
> > The Processor currently is already available to a
> ProcessingNode from
> > the Context so a ProcessingNode implementing
> Contextualizable will be
> > able to get to the EnvironmentHelper via that route.
> >
> Ah, ok, so what do you t
Unico Hommes wrote:
>
> The Processor currently is already available to a ProcessingNode from
> the Context so a ProcessingNode implementing Contextualizable will be
> able to get to the EnvironmentHelper via that route.
>
Ah, ok, so what do you think of using that then?
I just noticed that the k
Carsten Ziegeler wrote:
>
> Sylvain Wallez wrote:
> > Two suggestions regarding sourceResolver and redirector:
> >
> > SourceResolver (the Cocoon one) is a legacy requirement because we
> > can't change the interface of actions, generators, etc, and
> is used by
> > the Processor (for Actions
Sylvain Wallez wrote:
> Two suggestions regarding sourceResolver and redirector:
>
> SourceResolver (the Cocoon one) is a legacy requirement because we can't
> change the interface of actions, generators, etc, and is used by the
> Processor (for Actions) and the pipelines (for SitemapModelCompon
Unico Hommes wrote:
Carsten Ziegeler wrote:
I am currently trying to get act nodes to work and am have a question about the source resolving in 2.2. Currently the environment source resolver is put into the object model in the PipelinesNode. However, now that the environment no longer implement
Carsten Ziegeler wrote:
>
> Unico Hommes wrote:
> > OK thanks. It looks like we had the same idea :-). I went ahead and
> > implemented it the way you describe in option b) . I also added two
> > static helper methods to EnvironmentHelper: getSourceResolver and
> > getRedirector so we don't
Unico Hommes wrote:
> OK thanks. It looks like we had the same idea :-). I went ahead and
> implemented it the way you describe in option b) . I also added two
> static helper methods to EnvironmentHelper: getSourceResolver and
> getRedirector so we don't have to pass in the processor instance.
Goo
Carsten Ziegeler wrote:
>
> >
> > I am currently trying to get act nodes to work and am have
> a question
> > about the source resolving in 2.2. Currently the environment source
> > resolver is put into the object model in the PipelinesNode.
> However,
> > now that the environment no longer
>
> I am currently trying to get act nodes to work and am have a question
> about the source resolving in 2.2. Currently the environment source
> resolver is put into the object model in the PipelinesNode. However, now
> that the environment no longer implements SourceResolver but appears to
> be i
31 matches
Mail list logo
