Stephan Michels wrote:
[...]
Anyway, how that tool works is flawed, and will not necessarily work
with all pipelines (this came out in the Stammtisch), since they might
rely on the events being processed through the whole pipeline instead of
being cached.
Do you mean the 'Captor' component or
On Thu, 12 Dec 2002, Nicola Ken Barozzi wrote:
>
> Bruno Dumon wrote:
> > On Thu, 2002-12-12 at 10:44, Steven Noels wrote:
> >
> >>Christian Haul wrote:
> >>
> >>
> >>>On 12.Dec.2002 -- 10:08 AM, [EMAIL PROTECTED] wrote:
> >>>
> >>>
> Anyway, whatever the outcome I look forward to this new d
[EMAIL PROTECTED] wrote:
In addition we have implemented part of a debugger (consisting of another
plugin and the Cocoon side) that some of you saw in Ghent. Sylvain posted
the link to a screenshot earlier.
Yes, and it looks cool indeed.
At the moment I am trying to convince "the powers" that
[EMAIL PROTECTED] wrote:
Here is how the current version of our debugger works (as shown in Gent):
1) It is a remote debugger. This means that the client (the eclipse plugin)
connects to the Cocoon side of things using a socket.
This is our intention too.
2) As the request is processed by Co
Christian Haul wrote:
On 12.Dec.2002 -- 10:08 AM, [EMAIL PROTECTED] wrote:
Anyway, whatever the outcome I look forward to this new development as it
certainly is something that is needed badly. Perhaps Gianugo and Nicola
could provide some details on what they are thinking of?
What we were di
Bruno Dumon wrote:
On Thu, 2002-12-12 at 10:44, Steven Noels wrote:
Christian Haul wrote:
On 12.Dec.2002 -- 10:08 AM, [EMAIL PROTECTED] wrote:
Anyway, whatever the outcome I look forward to this new development as it
certainly is something that is needed badly. Perhaps Gianugo and Nicola
On Thu, 2002-12-12 at 10:53, [EMAIL PROTECTED] wrote:
[...]
> 3) It is a "2-phase" degugger. The first phase allows you to follow the
> route the request takes through the sitemap. This can happen step-by-step
> (or more exactly, component by component). The second phase then provides
> the xml do
On Thu, 2002-12-12 at 10:44, Steven Noels wrote:
> Christian Haul wrote:
>
> > On 12.Dec.2002 -- 10:08 AM, [EMAIL PROTECTED] wrote:
> >
> >>Anyway, whatever the outcome I look forward to this new development as it
> >>certainly is something that is needed badly. Perhaps Gianugo and Nicola
> >>cou
Here is how the current version of our debugger works (as shown in Gent):
1) It is a remote debugger. This means that the client (the eclipse plugin)
connects to the Cocoon side of things using a socket.
2) As the request is processed by Cocoon, an adapted TreeProcessor sends
events to the clien
Christian Haul wrote:
On 12.Dec.2002 -- 10:08 AM, [EMAIL PROTECTED] wrote:
Anyway, whatever the outcome I look forward to this new development as it
certainly is something that is needed badly. Perhaps Gianugo and Nicola
could provide some details on what they are thinking of?
What we were d
On 12.Dec.2002 -- 10:08 AM, [EMAIL PROTECTED] wrote:
> Anyway, whatever the outcome I look forward to this new development as it
> certainly is something that is needed badly. Perhaps Gianugo and Nicola
> could provide some details on what they are thinking of?
What we were discussing is a possibi
I have been following the discussion about a Cocoon IDE, debugger etc. with
some interest (although my email connection is limited this week). As most
of you know we have developed some plugins for eclipse that can help with
Cocoon based application development. You can download "sunBow" from here
12 matches
Mail list logo
