Hi Upayavira,
This looks real good, having a specialized testing framework will
certainly help improving our test traceability!
I just have one small thing to add:
...CocoonUnit would use the CocoonBean to pass requests to Cocoon. The
bean would prepare an Environment (maybe even an
Unico Hommes wrote:
snip/
CallFunctionNode.java ln 166/184:
// FIXME (SW) : is a flow allowed not to redirect ?
;-D
Uh (again)? I'm wondering if there's not a misunderstanding here: this FIXME is about knowing if a flowscript is allowed to terminate without stating what page it to be
On Wednesday, October 29, 2003, at 05:10 PM, Christopher Oliver wrote:
Can you recreate this problem with a simple example you can post to
the list?
I tried a simple replication of the problem, but so far, it still
behaves properly.
Still looking into it.
regards Jeremy
Jeremy Quinn wrote:
From: Sylvain Wallez
But I'm also wondering, as woody usage increases, if we will
not need to
write form templates involving more and more conditional
parts. And for
this, JXTemplate shines. But mixing jx-like access to the form model
with wt: templates elements is likely to quickly
From: Marc Portier
snip/
So as a recap:
Given the fact that todays browser behaviour is coupling
1. the encoding of the HTML-stream (from server to browser)
describing
the form
to
2. the encoding used to encode the request params in the HTTP-request
hosting the form-submit (from
Reinhard Poetz wrote:
From: Sylvain Wallez
But I'm also wondering, as woody usage increases, if we will not need to write form templates involving more and more conditional parts. And for this, JXTemplate shines. But mixing jx-like access to the form model with wt: templates elements is
Yes, thank you Marc!
I would prefer iso-8859-1 but this is just a feeling and no opinion
based on facts ;-)
me, too
IIRC correctly at dff we had some encoding issues in the past
...all I remember was we switched to to iso-8859-1 and they
were gone.
...but they might have been caused by the exact
On Sunday, Nov 2, 2003, at 20:32 Europe/Rome, Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:
3) move the whole thing into core
-1, the core should only contain necessary components.
+1, I wouldn't mind seeing it in core. It's like instrumentation
manager which is also in core.
which I
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: maandag 3 november 2003 9:52
To: [EMAIL PROTECTED]
Unico Hommes wrote:
snip/
We were talking about the fact that it seemed impossible to
serve a request without also sending an entity body along
On Monday, Nov 3, 2003, at 01:00 Europe/Rome, Ugo Cei wrote:
[I'm crossposting to dev, since this might stimulate some comments
from the Flowscript gurus over there.]
Oleg Dulin wrote:
Dear Fellow Cocoon Users:
I just read the forwarded message on xml-dev mailing list and
realized that Groovy
instrumentation block can be a good place for both.
The problem is that the instrumentation code is not (easily)
modularizable as it's intermixed with a bunch of places (in short, is an
aspect, not an object).
I haven't looked into this yet but... Doesn't instrumentation also work
through java
On Sun, 2 Nov 2003, Stefano Mazzocchi wrote:
On Sunday, Nov 2, 2003, at 15:57 Europe/Rome, Vadim Gritsenko wrote:
Stephan Michels wrote:
On Sun, 2 Nov 2003, Stefano Mazzocchi wrote:
On Saturday, Nov 1, 2003, at 23:29 Europe/Rome, Steve K wrote:
And finally, on a somewhat
but it doesn't seem very probable that Groovy will support
continuations any time soon, which is a pity.
Pretty cool stuff. If they add continuations, I'm all for throwin rhino
down the drain.
maybe if *they* don't do it *we* could do it...
maybe they are more willing to accept this feature?!
Stefano Mazzocchi wrote:
snip/
Pretty cool stuff. If they add continuations, I'm all for throwin
rhino down the drain.
[at least, from a community perspective, we wouldn't be basing our
entire architecture on branched code of a almost-dead community hosted
in a location that doesn't care
On Monday, Nov 3, 2003, at 09:52 Europe/Rome, Sylvain Wallez wrote:
Unico Hommes wrote:
snip/
CallFunctionNode.java ln 166/184:
// FIXME (SW) : is a flow allowed not to redirect ?
;-D
Uh (again)? I'm wondering if there's not a misunderstanding here:
this FIXME is about knowing if a flowscript
Stefano Mazzocchi [EMAIL PROTECTED] writes:
Today, for example, I found out that Cadaver and DAVExplorer don't
talk DeltaV to Slide... :- and I can't get Catacomb or Subversion
to build on merlino. I'm sooo depressed. :-(
Both do DeltaV for me. I am using current slide server from CVS
Sylvain Wallez wrote:
Unico Hommes wrote:
Sylvain Wallez wrote:
Unico Hommes wrote:
snip/
I just had a look at the code, seems it was already a FIXME on
Sylvain's list. Can I go ahead and make this change?
Uh? Where's that list??
CallFunctionNode.java ln 166/184: // FIXME (SW) :
Unico Hommes wrote:
snip/
IMO, this should be handled at the pipeline level, i.e. on a HEAD request, the pipeline should be built and setup, but not executed. And this for several reasons:
- not every request is handled by flowscript
- some pipeline components set response headers, such as the
On Monday, Nov 3, 2003, at 12:11 Europe/Rome, Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
snip/
Pretty cool stuff. If they add continuations, I'm all for throwin
rhino down the drain.
[at least, from a community perspective, we wouldn't be basing our
entire architecture on branched code
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
snip/
Uh (again)? I'm wondering if there's not a misunderstanding here:
this FIXME is about knowing if a flowscript is allowed to terminate
without stating what page it to be displayed, i.e. check if one of
sendPage(), sendPageAndWait() or
Stefano Mazzocchi wrote:
On Monday, Nov 3, 2003, at 09:52 Europe/Rome, Sylvain Wallez wrote:
Unico Hommes wrote:
snip/
CallFunctionNode.java ln 166/184:
// FIXME (SW) : is a flow allowed not to redirect ?
;-D
Uh (again)? I'm wondering if there's not a misunderstanding here:
this FIXME is
On Saturday, Nov 1, 2003, at 19:27 Europe/Rome, Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
On Saturday, Nov 1, 2003, at 12:09 Europe/Rome, Guido Casper wrote:
See also:
http://marc.theaimsgroup.com/?t=10631375302r=1w=2
Great, so it's a bug.
What's the status of this? has it been
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
snip/
Uh (again)? I'm wondering if there's not a misunderstanding here:
this FIXME is about knowing if a flowscript is allowed to terminate
without stating what page it to be displayed, i.e. check if one of
sendPage(),
I propose to remove the IDL-docs because they are far from being
up-to-date and the Flow-API is well-described in our usual docs.
Here my +1.
--
Reinhard
-Original Message-
From: Reinhard Poetz [mailto:[EMAIL PROTECTED]
Sent: Friday, October 31, 2003 8:34 AM
To: [EMAIL PROTECTED]
Antonio Gallardo wrote:
Stefano Mazzocchi dijo:
On Saturday, Nov 1, 2003, at 23:29 Europe/Rome, Steve K wrote:
And finally, on a somewhat unrelated subject, one thing that I've
always wanted Cocoon to do may be possible if support for collecting
the XML at each pipeline step is added. To aid
I'll be honest with you, I remembered the last time I got involved in the COcoon
internals, and based on the state of the project at that time, I could easily
upgrade to Fortress. However things are much different now, and there are a
number of places that Cocoon is deeply wed to ECM.
I no longer
Bruno Dumon wrote:
On Sat, 2003-11-01 at 16:20, Marc van Kempen wrote:
Bruno Dumon wrote:
On Fri, 2003-10-31 at 22:54, Marc van Kempen wrote:
Bruno Dumon wrote:
snip/
My first thought was to do this cleanup stuff serverside (could be as
simple as an XSL, which would make it easily
Reinhard Poetz wrote:
I propose to remove the IDL-docs because they are far from being
up-to-date and the Flow-API is well-described in our usual docs.
Here my +1.
+1 for me.
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
From: Christopher Oliver
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
snip/
Pretty cool stuff. If they add continuations, I'm all for throwin
rhino down the drain.
[at least, from a community perspective, we wouldn't be basing our
entire architecture on branched code of a
Christopher Oliver wrote:
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
snip/
Pretty cool stuff. If they add continuations, I'm all for throwin
rhino down the drain.
[at least, from a community perspective, we wouldn't be basing our
entire architecture on branched code of a almost-dead
On Mon, 2003-11-03 at 14:59, Marc van Kempen wrote:
Bruno Dumon wrote:
On Sat, 2003-11-01 at 16:20, Marc van Kempen wrote:
Bruno Dumon wrote:
On Fri, 2003-10-31 at 22:54, Marc van Kempen wrote:
Bruno Dumon wrote:
snip/
My first thought was to do this cleanup stuff serverside
Giacomo Pati wrote:
Reinhard Poetz wrote:
I propose to remove the IDL-docs because they are far from being
up-to-date and the Flow-API is well-described in our usual docs.
Here my +1.
+1 for me.
+1 here, too
Tony
Le Lundi, 3 nov 2003, à 17:14 Europe/Zurich, Tony Collen a écrit :
I propose to remove the IDL-docs because they are far from being
up-to-date and the Flow-API is well-described in our usual docs.
+1
-Bertrand
It only makes sense to roll back and start concentrating on Cocoon Blocks
at this time.
I do highly recommend refactoring Cocoon bit by bit to remove ECM assumptions
wherever they exist so that the actual upgrade to Fortress or Merlin will be
much simpler.
+1 from me.
Berin Loritsch wrote:
I'll
Le Lundi, 3 nov 2003, à 17:18 Europe/Zurich, Berin Loritsch a écrit :
It only makes sense to roll back and start concentrating on Cocoon
Blocks
at this time
+1
...Now if anyone wants to hire me so that I can work on it full time,
then
there will be no excuse ;P...
This would be even better
Berin Loritsch wrote:
It only makes sense to roll back and start concentrating on Cocoon Blocks
at this time.
I do highly recommend refactoring Cocoon bit by bit to remove ECM
assumptions
wherever they exist so that the actual upgrade to Fortress or Merlin
will be
much simpler.
+1 from me.
Quoting Reinhard Poetz [EMAIL PROTECTED]:
rhino-continuations in our CVS will make it easier to learn because it
lowers the barrier to 'play' with it. the only problem is that the most
of us aren't very familiar with the way how language interpreters work.
Maybe you can give as some pointer
Torsten Curdt wrote:
Berin Loritsch wrote:
It only makes sense to roll back and start concentrating on Cocoon Blocks
at this time.
I do highly recommend refactoring Cocoon bit by bit to remove ECM
assumptions
wherever they exist so that the actual upgrade to Fortress or Merlin
will be
much
Hi all,
I've added a new row-action widget to Woody. This widget implements
some of the frequently needed row management actions, such as adding a
row below the current one, deleting the current row or moving it up and
down.
This widget is different from repeater-action because it must be a
Berin, is it more the lack of time or more the tight
coupling with ECM?
I was so glad to see this effort and I am wondering
...how much ...and what is left to do? Maybe you
could give a summary of what you came across?
Maybe you just need some more helping hands?
Here is what is left to do:
*
Berin Loritsch wrote:
Unico Hommes wrote:
- Recomposable / Reconfigurable interfaces: no solution yet, needs
refactoring.
We need to make these unneeded.
- Support for current sitemap syntax instead of Fortress shorthand
syntax (?)
Easy enough to do. All you need to do
Berin Loritsch wrote:
...
I have a feeling the timings are useless largely because of the granularity
of the System.getTimeInMillis() method. On Windows the granularity is
10 ms.
If the timing is less than that it registers as 0. Add enough zeros and it
will always be less than the total time
On 03.11.2003 17:18, Berin Loritsch wrote:
It only makes sense to roll back and start concentrating on Cocoon Blocks
at this time.
I do highly recommend refactoring Cocoon bit by bit to remove ECM
assumptions
wherever they exist so that the actual upgrade to Fortress or Merlin
will be
much
On 03.11.2003 13:29, Reinhard Poetz wrote:
I propose to remove the IDL-docs because they are far from being
up-to-date and the Flow-API is well-described in our usual docs.
Here my +1.
+1
Joerg
Joerg Heinicke wrote:
On 03.11.2003 17:18, Berin Loritsch wrote:
It only makes sense to roll back and start concentrating on Cocoon
Blocks
at this time.
I do highly recommend refactoring Cocoon bit by bit to remove ECM
assumptions
wherever they exist so that the actual upgrade to Fortress
Reinhard Poetz wrote:
I propose to remove the IDL-docs because they are far from being
up-to-date and the Flow-API is well-described in our usual docs.
Here my +1.
+1
Geoff
Torsten Curdt wrote:
Berin, is it more the lack of time or more the tight
coupling with ECM?
I was so glad to see this effort and I am wondering
...how much ...and what is left to do? Maybe you
could give a summary of what you came across?
Maybe you just need some more helping hands?
Here is
Torsten Curdt wrote:
Berin, is it more the lack of time or more the tight
coupling with ECM?
I was so glad to see this effort and I am wondering
...how much ...and what is left to do? Maybe you
could give a summary of what you came across?
Maybe you just need some more helping hands?
Here is
Joerg Heinicke wrote:
On 03.11.2003 11:01, Reinhard Poetz wrote:
Yes, thank you Marc!
I would prefer iso-8859-1 but this is just a feeling and no opinion
based on facts ;-)
Even if it's only one parameter to change I would like to support
non-ISO-characters by default and so prefer UTF-8.
Reinhard Poetz wrote:
From: Christopher Oliver
If you're concerned about community support why not add the
Rhino-with-continuations source to the Cocoon cvs.
I hope this will happen in the next weeks. I discuessed this with Steven
and he has already offered to shepard the integration (licence
Berin Loritsch dijo:
It only makes sense to roll back and start concentrating on Cocoon
Blocks at this time.
I do highly recommend refactoring Cocoon bit by bit to remove ECM
assumptions wherever they exist so that the actual upgrade to Fortress
or Merlin will be much simpler.
+1 from me.
Berin Loritsch wrote:
Sylvain Wallez wrote:
Sure I will. It would clearly be a bad thing to trash the time and
effort Bering has put there. I may not have the required time to do
it by myself, but I'm ready to answer questions. So maybe with the
combined support of Berin and me we can turn
On Nov 3, 2003, at 4:33 PM, Berin Loritsch wrote:
Anyhoo, the basic solution is to either build a tree/graph of pure
components
or a tree/graph of pure beans. Either solution will work. We need to
get rid
of the need for the LifecycleHelper type class. I would lean more
toward the
bean
peter royal dijo:
On Nov 3, 2003, at 4:33 PM, Berin Loritsch wrote:
Anyhoo, the basic solution is to either build a tree/graph of pure
components
or a tree/graph of pure beans. Either solution will work. We need to
get rid
of the need for the LifecycleHelper type class. I would lean more
---
This mail is generated automatically using
Jakarta Ant. Contents are automatically
downloaded from Apache's Bugzilla.
---
Please do not reply to
peter royal wrote:
Anyone:
Any thoughts about using Jelly as the builder for the sitemap?
Its usage can be completely hidden, but as a tag processor, it might
work very well. We could use it to construct a bean-graph to model the
sitemap.
-pete
Sounds sensible. Is jelly in use anywhere else
I see there has been some discussion about continuations on their ML:
http://lists.codehaus.org/pipermail/groovy-dev/2003q3/000158.html
but it doesn't seem very probable that Groovy will support continuations
any time soon, which is a pity.
How about XSP ? I can certainly see it as a
Oleg Dulin wrote:
I see there has been some discussion about continuations on their ML:
http://lists.codehaus.org/pipermail/groovy-dev/2003q3/000158.html
but it doesn't seem very probable that Groovy will support continuations
any time soon, which is a pity.
How about XSP ? I can certainly
[EMAIL PROTECTED] wrote:
The lookup/release add/remove the component to/from an ArrayList. If you
have a lot of Components which lookup other Components inside the compose
method the List can be really big. If you have a lot of SubSitemaps which
use many InputModules it grows and grows . and
[EMAIL PROTECTED] wrote:
The lookup/release add/remove the component to/from an ArrayList. If you
have a lot of Components which lookup other Components inside the
compose
method the List can be really big. If you have a lot of SubSitemaps
which
use many InputModules it grows and grows
60 matches
Mail list logo
