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
components
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 the
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 node
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 sitemap
Geoff Howard wrote:
Sylvain Wallez wrote:
Unico Hommes wrote:
snip/
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
Sylvain Wallez wrote:
Geoff Howard wrote:
Sylvain Wallez wrote:
Unico Hommes wrote:
snip/
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.
Sylvain Wallez wrote:
Geoff Howard wrote:
Sylvain Wallez wrote:
Unico Hommes wrote:
snip/
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
: 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:
snip/
BTW, Unico, I don't know what is your
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
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 wrote:
Unico Hommes wrote:
snip/
BTW, Unico, I
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
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 with
Geoff Howard wrote:
Sylvain Wallez wrote:
Geoff Howard wrote:
Sylvain Wallez wrote:
Unico Hommes wrote:
snip/
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
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,
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
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
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) and the
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 key
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 think of using
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 still a TODO
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,
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
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 implements
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.
Good!
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 have to
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
26 matches
Mail list logo
