On Sat, Apr 03, 2004 at 01:58:51PM -0800, Christopher Oliver wrote:
These ContinuationsManager API should _not_ be used in a flowscript. Use
the sitemap to invoke your continuation, please.
Is it possible to solve your problem by using a helper function to send
the page:
function
On Sat, Apr 03, 2004 at 11:17:42PM -0800, Christopher Oliver wrote:
contManager = null;
try {
contManager = cocoon.getComponent
( org.apache.cocoon.components.flow.ContinuationsManager );
var wk = contManager.lookupWebContinuation( continuationId );
} finally {
if ( contManager != null )
Hello (Guido),
I have done a small js file to test the functionalities of the new
WebDAVRepository[1] using the NEW Repository[2] interface.
I encountered a problem creating new reosurces.
It does not work when using saveContent(String, String) on the [1]/[2].
Normally, looking at the
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
On Apr 3, 2004, at 9:35 PM, Sylvain Wallez wrote:
leo leonid wrote:
On Apr 3, 2004, at 5:55 PM, Joerg Heinicke wrote:
On 02.04.2004 19:42, leo leonid wrote:
I can't confirm that wd:submit validate=false/ functionality
is restored.
It's OK in Revision 1.2 though. Or did the syntax change?
Christopher Oliver wrote:
Leszek Gawron wrote:
cocoon.handleContinuation( wk.getContinuation() );
lg
Uh, it doesn't actually work properly in general, as you noticed (with
page locals). Also Cocoon.handleContinuation() is an internal function
that shouldn't be called except by Cocoon
Tony Collen wrote:
Christopher Oliver wrote:
Leszek Gawron wrote:
cocoon.handleContinuation( wk.getContinuation() );
lg
Uh, it doesn't actually work properly in general, as you noticed (with
page locals). Also Cocoon.handleContinuation() is an internal function
that shouldn't be
Uh, thanks. But Leszek is talking about the JS function
handleContinuation() defined in fom_system.js - not the Java method that
you point out. That method is not accessible to flowscripts.
Chris
Tony Collen wrote:
Tony Collen wrote:
Christopher Oliver wrote:
Leszek Gawron wrote:
Leszek Gawron wrote:
On Sat, Apr 03, 2004 at 01:58:51PM -0800, Christopher Oliver wrote:
These ContinuationsManager API should _not_ be used in a flowscript. Use
the sitemap to invoke your continuation, please.
Is it possible to solve your problem by using a helper function to send
the
Christopher Oliver wrote:
Uh, thanks. But Leszek is talking about the JS function
handleContinuation() defined in fom_system.js - not the Java method that
you point out. That method is not accessible to flowscripts.
Ahh, ok, I understand now.
Regards,
Tony
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28189.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28189.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Jon Evans wrote:
HTTP/1.x 200 OK
Date: Fri, 02 Apr 2004 15:43:04 GMT
Server: Jetty/4.2.14 (Mac OS X/10.3.3 ppc java/1.4.2_03)
X-Cocoon-Version: 2.1.5-dev
Transfer-Encoding: chunked
Expires: Thu, 01 Jan 2000 00:00:00 GMT == HERE
Content-Type: text/html
Cache-Control: no-cache == HERE
Pragma:
Sylvain Wallez wrote:
Andrzej Jan Taramina wrote:
...
persistent-store logger=core.store.persistent
parameter name=use-cache-directory value=true/
parameter name=order value=2701/
/persistent-store
An aside...what the heck is the order value anyway?
No idea :-/
I don't know for sure but I
Leszek Gawron wrote:
On Sat, Apr 03, 2004 at 01:58:51PM -0800, Christopher Oliver wrote:
These ContinuationsManager API should _not_ be used in a flowscript. Use
the sitemap to invoke your continuation, please.
Is it possible to solve your problem by using a helper function to send
the
Geoff Howard wrote:
Sylvain Wallez wrote:
Andrzej Jan Taramina wrote:
...
persistent-store logger=core.store.persistent
parameter name=use-cache-directory value=true/
parameter name=order value=2701/
/persistent-store
An aside...what the heck is the order value anyway?
No idea :-/
I
Sylvain Wallez wrote:
Geoff Howard wrote:
Sylvain Wallez wrote:
Andrzej Jan Taramina wrote:
...
persistent-store logger=core.store.persistent
parameter name=use-cache-directory value=true/
parameter name=order value=2701/
/persistent-store
An aside...what the heck is the order value
Antonio Gallardo wrote:
Hi:
Hi:
Some of us wanted to see Groovy support in Cocoon. Now we can play a
little with Groovy using the recently added support for Groovy script
generator under the BSF block. More info about how to use it is here:
Stefano Mazzocchi wrote:
Antonio Gallardo wrote:
Hi:
Hi:
Some of us wanted to see Groovy support in Cocoon. Now we can play a
little with Groovy using the recently added support for Groovy script
generator under the BSF block. More info about how to use it is here:
Geoff Howard wrote:
Sylvain Wallez wrote:
Geoff Howard wrote:
snip/
I don't know for sure but I think it's the order of the index used
by the JISP impl.
Thanks for this enlightning explanation, but erm... what is the
order of an index???
;-)
Sylvain Wallez wrote:
Geoff Howard wrote:
Sylvain Wallez wrote:
Geoff Howard wrote:
snip/
I don't know for sure but I think it's the order of the index used
by the JISP impl.
Thanks for this enlightning explanation, but erm... what is the
order of an index???
;-)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28189.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28189.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28189.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28189.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi !
I have found this message at sitemap.log (cocoon 2.1.4 / tomcat 4.1.24):
WARN(2004-04-04) 23:30.03:780 [sitemap.generator.serverpages]
(/cocoon/mcp/main) Thread-10/AbstractEsqlConnection: Your database
[db2/6000] is not being recognized yet. Using the generic [jdbc] query as
default.
Hi:
Yesterday, I spent the last 4 hours reading about Groovy and studing the
current JavaFlow implementation try find a way to create the long awaited:
GroovyFlow Engine with Continuations.
I think the Groovy continuation can be implemented on the base of the
current JavaFlow. We just need to
in the past I was used to:
1) cp blocks.properties local.blocks.properties
2) vi local.blocks.properties
3) uncomment the blocks that I wanted to exclude
Today, I have to go thru a bunch of include and change them from true to
false. Much more hassle than just uncommenting/commenting one
Stefano Mazzocchi dijo:
Next I would like to see is a groovy implementation of flow ;-)
Wait a few hours. I will try to make it work now
Best Regards,
Antonio Gallardo
Geoff Howard dijo:
Sylvain Wallez wrote:
http://www.coyotegulch.com/jisp/docs/com/coyotegulch/jisp/BTreeIndex.html#BTreeIndex(java.lang.String,%20int,%20boolean)
Ah, ok! Thanks!
But, erm... where does this 2701 come from? And yes, I googled for
JISP 2701 before asking ;-)
Unfortunately I
Stefano Mazzocchi wrote:
in the past I was used to:
1) cp blocks.properties local.blocks.properties
2) vi local.blocks.properties
3) uncomment the blocks that I wanted to exclude
Today, I have to go thru a bunch of include and change them from true to
false. Much more hassle than just
I will be surprised if continuations based around the Cocoon javaflow
implementation don't leak into Groovy CVS based on the amount of
chatter in #groovy about continuations.
I know James wants this very much, and hacked out a way to do it via
exceptions once (and hacked is the correct
Tony Collen dijo:
Stefano Mazzocchi wrote:
in the past I was used to:
1) cp blocks.properties local.blocks.properties
2) vi local.blocks.properties
3) uncomment the blocks that I wanted to exclude
Today, I have to go thru a bunch of include and change them from true to
false. Much more
Brian McCallister dijo:
I will be surprised if continuations based around the Cocoon javaflow
implementation don't leak into Groovy CVS based on the amount of
chatter in #groovy about continuations.
I know James wants this very much, and hacked out a way to do it via
exceptions once (and
On 05.04.2004 00:18, Stefano Mazzocchi wrote:
in the past I was used to:
1) cp blocks.properties local.blocks.properties
2) vi local.blocks.properties
3) uncomment the blocks that I wanted to exclude
Today, I have to go thru a bunch of include and change them from true to
false. Much more
On 05.04.2004 04:31, Antonio Gallardo wrote:
in the past I was used to:
1) cp blocks.properties local.blocks.properties
2) vi local.blocks.properties
3) uncomment the blocks that I wanted to exclude
Today, I have to go thru a bunch of include and change them from true to
false. Much more hassle
The current implementation needs some work to qualify as generalized
Java continuations. It would be nice to make it work more like Scheme
continuations:
1) When you access the current continuation, it captures the call
stack up to but not including the current method (and makes a (shallow)
On 05.04.2004 02:41, Antonio Gallardo wrote:
Hi:
Currently, the optional libs always are copied to the resulted build.
Seems like it is the same as puting them in lib/core dir. That apporach is
not good at all. I would like to see an extension of the current Cocoon
build system that will check
Joerg Heinicke dijo:
But the real need for changing it came out of the discussion about
default excludes of blocks (e.g. javaflow or all unstable blocks). You
have *no* possibility to re-include a block then in
local.blocks.properties.
Yes you have a posibility. I posted, while I developed
On 05.04.2004 04:53, Antonio Gallardo wrote:
But the real need for changing it came out of the discussion about
default excludes of blocks (e.g. javaflow or all unstable blocks). You
have *no* possibility to re-include a block then in
local.blocks.properties.
Yes you have a posibility. I
Joerg Heinicke dijo:
On 05.04.2004 02:41, Antonio Gallardo wrote:
Hi:
Currently, the optional libs always are copied to the resulted build.
Seems like it is the same as puting them in lib/core dir. That apporach
is
not good at all. I would like to see an extension of the current Cocoon
Joerg Heinicke dijo:
On 05.04.2004 04:53, Antonio Gallardo wrote:
But the real need for changing it came out of the discussion about
default excludes of blocks (e.g. javaflow or all unstable blocks). You
have *no* possibility to re-include a block then in
local.blocks.properties.
Yes you have
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27020.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Tony Collen wrote:
Stefano Mazzocchi wrote:
in the past I was used to:
1) cp blocks.properties local.blocks.properties
2) vi local.blocks.properties
3) uncomment the blocks that I wanted to exclude
Today, I have to go thru a bunch of include and change them from true
to false. Much more
44 matches
Mail list logo
