Stefano Mazzocchi wrote:
Reinhard Poetz wrote:
More information and explanations can be found at
http://wiki.apache.org/cocoon/CocoonBlockBuilder
[not critizing, just curious] can you explain why you think that having
block/lib is going to be jar hell while lib/block is not?
I would really like
Folks please cast your votes for:
[ ] Leszek
[ ] Ralph
as Apache Cocoon committers.
+1 for both,
welcome Ralph and Leszek!
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog at
Tony Collen wrote:
Do we need a new, (standardized?) or possibly even *gasp* better
templating system for Cocoon? This is where I encourage people to dive
in and give their own [RT]s and thoughts on the issue.
First, thank you for the pointer. Interesting stuff.
But first, we should agree on
On Fri, 29 Oct 2004, Reinhard Poetz wrote:
Tony Collen wrote:
Do we need a new, (standardized?) or possibly even *gasp* better
templating system for Cocoon? This is where I encourage people to dive
in and give their own [RT]s and thoughts on the issue.
First, thank you for the pointer.
Reinhard Poetz wrote:
Tony Collen wrote:
Do we need a new, (standardized?) or possibly even *gasp* better
templating system for Cocoon? This is where I encourage people to
dive in and give their own [RT]s and thoughts on the issue.
First, thank you for the pointer. Interesting stuff.
But
Sylvain Wallez wrote:
XPath is a must-have when you deal with XML documents while
Jexl is mostly useless in that case but is straightforward
when you deal with JavaBeans. I also agree that understanding
the difference between ${continuation.id} and
#{$continuation/id} is less than
Le 29 oct. 04, à 10:17, Carsten Ziegeler a écrit :
...Hmm, one of the things I really don't like with JXTG is that you
have to different expression languages. You never know which to
use and some things work only with one specific language.
And for me this comes near to FS :)
Yes - but
The current implementation of our continuations manager uses
the excalibur event package for the background checker that
checks for expired continuations.
Now, this approach has the problem, that excalibur event is
deprecated. In addition we aren't using it somewhere else,
so it would be great if
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
XPath is a must-have when you deal with XML documents while
Jexl is mostly useless in that case but is straightforward
when you deal with JavaBeans. I also agree that understanding
the difference between ${continuation.id} and
Bertrand Delacretaz wrote:
I don't think JXTG is broken now, it works well but the code
is hard to understand and having all classes in a single huge
source code file does not help.
Yupp, that is one of the problems with JXTG. It would be great if
a new solution would be pluggable to add
Sylvain Wallez wrote:
That's exactly what I suggest above: we choose a standard
default language, but open the possibility to plug in new
ones. XPath is a must-have, Jexl and IM have very valid use
cases which IMO justify them to be provided by Cocoon. Other
languages are just a
-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
Sent: Friday, October 29, 2004 10:47 AM
To: [EMAIL PROTECTED]
Subject: RE: [RT] StringTemplate: The answer to our templating needs?
Bertrand Delacretaz wrote:
I don't think JXTG is broken now, it works well
Carsten Ziegeler wrote:
The current implementation of our continuations manager uses
the excalibur event package for the background checker that
checks for expired continuations.
Now, this approach has the problem, that excalibur event is
deprecated. In addition we aren't using it somewhere else,
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=25951.
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=25283.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
The current implementation of our continuations manager uses
the excalibur event package for the background checker that
checks for expired continuations.
Now, this approach has the problem, that excalibur event is
deprecated. In addition we aren't
Carsten Ziegeler wrote:
The current implementation of our continuations manager uses
the excalibur event package for the background checker that
checks for expired continuations.
Now, this approach has the problem, that excalibur event is
deprecated. In addition we aren't using it somewhere else,
Giacomo Pati wrote:
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
The current implementation of our continuations manager uses the
excalibur event package for the background checker that checks for
expired continuations.
Now, this approach has the problem, that excalibur event is
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
That's exactly what I suggest above: we choose a standard
default language, but open the possibility to plug in new
ones. XPath is a must-have, Jexl and IM have very valid use
cases which IMO justify them to be provided by Cocoon. Other
languages
[EMAIL PROTECTED] wrote:
@@ -687,6 +703,7 @@
if (fun == Scriptable.NOT_FOUND) {
throw new ResourceNotFoundException(Function \javascript: + funName +
()\ not found);
}
+thrScope.setLock(true);
Stefano Mazzocchi wrote:
Reinhard Poetz wrote:
More information and explanations can be found at
http://wiki.apache.org/cocoon/CocoonBlockBuilder
[not critizing, just curious] can you explain why you think that having
block/lib is going to be jar hell while lib/block is not?
you can have one
Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
@@ -687,6 +703,7 @@
if (fun == Scriptable.NOT_FOUND) {
throw new
ResourceNotFoundException(Function \javascript: + funName + ()\
not found);
}
+
Hi All
At the GT, I got the chance to meet Antonio (oh joy !!) and one of the
many things we talked about was the possibility of him giving me some
help learning Apache ORO. He very graciously accepted!!!
I have a project, the o.a.c.bean.query.SimpleLuceneQuery, in Cocoon,
which is possibly an
Bart Molenkamp wrote:
Bertrand Delacretaz wrote:
I don't think JXTG is broken now, it works well but the
code is hard
to understand and having all classes in a single huge source code
file does not help.
Yupp, that is one of the problems with JXTG. It would be great if a
Tony Collen wrote:
--
Well, I was too quick on the key presses, so here goes again. Sorry for
the spam :)
--
Brought to you by the maniac that brings you ANTLR!
A while ago I was investigating different templating languages, and I
came across one
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
Giacomo Pati wrote:
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
The current implementation of our continuations manager uses the
excalibur event package for the background checker that checks for
expired continuations.
Now, this approach has the
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
XPath is a must-have when you deal with XML documents while
Jexl is mostly useless in that case but is straightforward
when you deal with JavaBeans. I also agree that understanding
the difference between ${continuation.id} and
#{$continuation/id}
Leszek Gawron wrote:
Stefano Mazzocchi wrote:
Reinhard Poetz wrote:
More information and explanations can be found at
http://wiki.apache.org/cocoon/CocoonBlockBuilder
[not critizing, just curious] can you explain why you think that
having block/lib is going to be jar hell while lib/block is
Carsten Ziegeler wrote:
Bart Molenkamp wrote:
Bertrand Delacretaz wrote:
I don't think JXTG is broken now, it works well but the
code is hard
to understand and having all classes in a single huge source code
file does not help.
Yupp, that is one of the problems with JXTG. It would be great if
Giacomo Pati wrote:
Yes, we used the CommandManager in some projects. It is based
on the PooledExecutor from Doug Leas concurrent-utils
package. It comes in quite handy as you can put tasks there
you'd like to be done asynchroniously (ie. indexing a
uploaded document with lucene to
Leszek Gawron wrote:
And if there are language constructs that are not possible to
implement with JXPath and JavaBeans? And I am sure there are
(I had some problems myself but shoot me in the head: I do
not remember the exact cases). Should we be saying to users:
it does not work with
What the meaning GT? What's that?
On Thu, 28 Oct 2004 13:08:08 -0400, JACOB, ERIC [EMAIL PROTECTED] wrote:
Hi,
I would be interested in that too. Anyone has tried out the demo at GT and
could provide some comments about the tool?
Eric
-Original Message-
From: Ralph Goers
Bart Molenkamp wrote:
-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
Sent: Friday, October 29, 2004 10:47 AM
To: [EMAIL PROTECTED]
Subject: RE: [RT] StringTemplate: The answer to our templating needs?
Bertrand Delacretaz wrote:
I don't think JXTG is broken now, it
Reinhard Poetz wrote:
No, you're right - this is a possible danger. But as long
as we only
make it pluggable and be careful that we don't fall into
this trap, I
see no problem with it.
The question is: Do we want to prevent our users from this or
is it their own decision?
Reinhard Poetz wrote:
No, you're right - this is a possible danger. But as long as we only
make it pluggable and be careful that we don't fall into this trap,
I see no problem with it.
The question is: Do we want to prevent our users from this or is it
their own decision?
Applying constraints on
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
It's their own decision. Now in the end you can't prevent users
from doing so - and perhaps, although we think that it's wrong it
might be exactly what they need for their use case. I definitly
have the need to plug my own tags into JXTG ;)
I cannot
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
Giacomo Pati wrote:
Yes, we used the CommandManager in some projects. It is based
on the PooledExecutor from Doug Leas concurrent-utils
package. It comes in quite handy as you can put tasks there
you'd like to be done asynchroniously (ie. indexing a
Giacomo Pati wrote:
Sure, no problem. How should it be named?
What does it do? :)
Someone mentioned Crons JobScheduler as it has a fireJob()
method that could do it but would we want the cron block go
into the core?
Hmm, I think this depends on the effort it takes to create it.
If we
I'll be attending the Glesstec [1] fair in Duesseldorf from Nov 8 to Nov
11.
It would be fun to meet up with some ASF folks there, maybe for a dinner
gettogether.
[1] http://www.glasstec-online.com/
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
Giacomo Pati wrote:
Sure, no problem. How should it be named?
What does it do? :)
Someone mentioned Crons JobScheduler as it has a fireJob()
method that could do it but would we want the cron block go
into the core?
Hmm, I think this depends on the
e-|vira wrote:
What the meaning GT? What's that?
http://www.orixo.com/events/gt2004/
--
Leszek Gawron [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67
Giacomo Pati wrote:
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
Giacomo Pati wrote:
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
The current implementation of our continuations manager uses the
excalibur event package for the background checker that checks for
expired continuations.
Now, this
Thanks
On Fri, 29 Oct 2004 13:45:53 +0200, Leszek Gawron [EMAIL PROTECTED] wrote:
e-|vira wrote:
What the meaning GT? What's that?
http://www.orixo.com/events/gt2004/
--
Leszek Gawron [EMAIL PROTECTED]
Project Manager
Unico Hommes wrote:
...
I believe that the excalibur event package lives on at d-haven [1]. Why
not use that?
Oh oh. We did this discussion with the container, I hope we don't have
to go over this again for every Avalon dependency we have ;-P
1. http://api.d-haven.org/event/
--
Nicola Ken
On 29.10.2004 13:07, Carsten Ziegeler wrote:
It's their own decision. Now in the end you can't prevent users
from doing so
But that's exactly what the document is about: *enforcing* separation
instead of *encourage*. StringTemplate claims to provide that.
Joerg
Nicola Ken Barozzi wrote:
Unico Hommes wrote:
...
I believe that the excalibur event package lives on at d-haven [1].
Why not use that?
Oh oh. We did this discussion with the container, I hope we don't have
to go over this again for every Avalon dependency we have ;-P
Nope just with
Frédéric Glorieux wrote:
I'm usually running multiple instances of same cocoon for debug
(different ports, different servletPath, to test under different
contexts and initParams). I know how to find my logs in such ways, but
with the config upper, it may be nice to have something like
Tony Collen wrote:
[EMAIL PROTECTED] wrote:
--- cocoon/branches/BRANCH_2_1_X/blocks.properties(original)
+++ cocoon/branches/BRANCH_2_1_X/blocks.propertiesThu Oct 28
14:51:15 2004
@@ -72,7 +72,6 @@
#include.block.lucene=false
#include.block.naming=false
#include.block.paranoid=false
Just a test. I was thinking I get bounces from some addresses whenever I
post here. Sorry for the inconvenience.
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
Le 29 oct. 04, à 12:41, Jeremy Quinn a écrit :
...What I hope to do is to make the Queries persistable in HSQLDB via
ORO...
ORO? That's a regexp package, do you mean OJB instead?
...I suppose one of the first questions that needs asking before going
ahead and making an Apache ORO equivalent to
Il giorno 29/ott/04, alle 12:41, Jeremy Quinn ha scritto:
What I hope to do is to make the Queries persistable in HSQLDB via ORO
and add this to Cocoon as a new Block, both as a sample and as a
useful module that should be easy to add to your own project.
I'm sure you meant OJB instead of ORO
On Oct 29, 2004, at 4:41 AM, Carsten Ziegeler wrote:
Yesterday, I wrote a simple replacement which I checked into 2.2:
a simple background thread is initialized that sleeps for a
configured period of time, checks the continuations, sleeps etc.
Now, this solution should work.
The question is now,
Le 29 oct. 04, à 12:59, Reinhard Poetz a écrit :
Bart Molenkamp wrote:
...
No, you're right - this is a possible danger. But as long as we only
make it pluggable and be careful that we don't fall into this trap,
I see no problem with it.
The question is: Do we want to prevent our users from this
Il giorno 29/ott/04, alle 11:26, Sylvain Wallez ha scritto:
java.util.TimerTask?
+1. Do the simplest thing that might possibly work. KISS, YAGNI, etc.
etc. etc.
Ugo
--
Ugo Cei - http://beblogging.com/
smime.p7s
Description: S/MIME cryptographic signature
On 29 Oct 2004, at 13:23, Ugo Cei wrote:
Il giorno 29/ott/04, alle 12:41, Jeremy Quinn ha scritto:
What I hope to do is to make the Queries persistable in HSQLDB via
ORO and add this to Cocoon as a new Block, both as a sample and as a
useful module that should be easy to add to your own project.
Jeremy Quinn wrote:
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !
On 29 Oct 2004, at 13:21, Bertrand Delacretaz wrote:
Le 29 oct. 04, à 12:41, Jeremy Quinn a écrit :
...What I hope to do is to make the Queries persistable in HSQLDB via
ORO...
ORO? That's a regexp package, do you mean OJB instead?
Yes groan ;)
...I suppose one of the first questions that needs
Nicola Ken Barozzi wrote:
Unico Hommes wrote:
...
I believe that the excalibur event package lives on at d-haven [1].
Why not use that?
Or we could stick with excalibur-event, if there is nothing wrong with it.
Oh oh. We did this discussion with the container, I hope we don't have
to go over
On 29 Oct 2004, at 13:37, Unico Hommes wrote:
Jeremy Quinn wrote:
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
That's exactly what I suggest above: we choose a standard
default language, but open the possibility to plug in new
ones. XPath is a must-have, Jexl and IM have very valid use
cases which IMO justify them to be provided by Cocoon. Other
Jeremy Quinn wrote:
On 29 Oct 2004, at 13:23, Ugo Cei wrote:
Il giorno 29/ott/04, alle 12:41, Jeremy Quinn ha scritto:
What I hope to do is to make the Queries persistable in HSQLDB via
ORO and add this to Cocoon as a new Block, both as a sample and as a
useful module that should be easy to add
Le 29 oct. 04, à 14:36, Jeremy Quinn a écrit :
...I'm sure you meant OJB instead of ORO here, right?
Yeah, sorry :)
OJB, OJB OJB . that is even worse than your OBJ mistake ;)
Although...implementing persistence based on ORO might be an
interesting exercise for a Friday afternoon ;-)
Il giorno 29/ott/04, alle 14:36, Jeremy Quinn ha scritto:
On 29 Oct 2004, at 13:23, Ugo Cei wrote:
Il giorno 29/ott/04, alle 12:41, Jeremy Quinn ha scritto:
What I hope to do is to make the Queries persistable in HSQLDB via
ORO and add this to Cocoon as a new Block, both as a sample and as a
Carsten Ziegeler wrote:
Bertrand Delacretaz wrote:
I don't think JXTG is broken now, it works well but the code
is hard to understand and having all classes in a single huge
source code file does not help.
Yupp, that is one of the problems with JXTG. It would be great if
a new solution would be
Carsten Ziegeler wrote:
Leszek Gawron wrote:
And if there are language constructs that are not possible to
implement with JXPath and JavaBeans? And I am sure there are
(I had some problems myself but shoot me in the head: I do
not remember the exact cases). Should we be saying to users:
it
On 29 Oct 2004, at 13:49, Ugo Cei wrote:
Il giorno 29/ott/04, alle 14:36, Jeremy Quinn ha scritto:
On 29 Oct 2004, at 13:23, Ugo Cei wrote:
Il giorno 29/ott/04, alle 12:41, Jeremy Quinn ha scritto:
What I hope to do is to make the Queries persistable in HSQLDB via
ORO and add this to Cocoon as a
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
That's exactly what I suggest above: we choose a standard default
language, but open the possibility to plug in new ones. XPath is a
must-have, Jexl and IM have very valid use cases which IMO justify
them to be provided by
Le 29 oct. 04, à 15:05, Vadim Gritsenko a écrit :
Sylvain Wallez wrote:
...Technically this should be possible, but how do we write something
like widget.getChild(foo).getAttribute(bar) in XPath?
Tecnically, this will be
getAttribute(getChild($widget, foo), bar)
in JXPath. Not exactly easy to
I just tried to make a redirect inside an error-handler and it
doesn't work as the redirector on the InvokeContext is not set.
So it seems that we have to set it in the ErrorHandlerHelper class
when the new error invoke context is created.
The question is now, which redirector implementation to
Vadim Gritsenko wrote:
like a template generator/transformer, input moduls, java code etc.
About Java code, do you mean in Actions, Transformers, etc?
Or, you mean flowscript beans?
No, I meant Action, Transformers etc.
Carsten
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
What can you do with Jexl what you can't do with an XPath based
language? My understanding is that they only differ in their syntax
('.' instead of '/').
Now even if Jexl has more functionality I don't see a reason why
this
Jeremy Quinn wrote:
On 29 Oct 2004, at 13:37, Unico Hommes wrote:
Jeremy Quinn wrote:
If email from this address is not signed
IT IS NOT FROM ME
Always check the
Bertrand Delacretaz wrote:
Le 29 oct. 04, à 15:05, Vadim Gritsenko a écrit :
Sylvain Wallez wrote:
...Technically this should be possible, but how do we write something
like widget.getChild(foo).getAttribute(bar) in XPath?
Tecnically, this will be
getAttribute(getChild($widget, foo), bar)
in
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
like a template generator/transformer, input moduls, java code etc.
About Java code, do you mean in Actions, Transformers, etc?
Or, you mean flowscript beans?
No, I meant Action, Transformers etc.
If you already thought about it, how would you pass
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Bertrand Delacretaz wrote:
Le 29 oct. 04, à 15:05, Vadim Gritsenko a écrit :
Sylvain Wallez wrote:
...Technically this should be possible, but how do we write something
like
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
like a template generator/transformer, input moduls, java code etc.
About Java code, do you mean in Actions, Transformers, etc?
Or, you mean flowscript beans?
No, I meant Action, Transformers etc.
If you
Vadim Gritsenko wrote:
Bertrand Delacretaz wrote:
Le 29 oct. 04, à 15:05, Vadim Gritsenko a écrit :
Sylvain Wallez wrote:
...Technically this should be possible, but how do we write
something like widget.getChild(foo).getAttribute(bar) in XPath?
Tecnically, this will be
Le 29 oct. 04, à 15:51, Sylvain Wallez a écrit :
Vadim Gritsenko wrote:
Bertrand Delacretaz wrote:
...
And technically in plain XPath it would be something like
//widget/foo/@bar
IIUC, JXPath has pluggable introspectors, so it above can be reduced
to:
$widget/foo/@bar
Eeek. Do you really
Vadim Gritsenko wrote:
Frédéric Glorieux wrote:
I'm usually running multiple instances of same cocoon for debug
(different ports, different servletPath, to test under different
contexts and initParams). I know how to find my logs in such ways, but
with the config upper, it may be nice to have
Vadim Gritsenko wrote:
PS You re-generated blocks.properties, not hand-edited it, right?
I hand-edited it at first, and then I found the re-generation script,
ran it, and the result was the same.
Vadim
Tony
I don't know if I'm right here, but...
- For java objects, Jexl can do more than JXPath.
- For DOM trees, JXPath is better (readible).
Maybe it's a good idea to configure the expression language you want to
use? E.g. in the configuration of the JXTG, or maybe passing it as a
parameter in
Bertrand Delacretaz wrote:
Le 29 oct. 04, à 15:51, Sylvain Wallez a écrit :
Vadim Gritsenko wrote:
Bertrand Delacretaz wrote:
...
And technically in plain XPath it would be something like
//widget/foo/@bar
IIUC, JXPath has pluggable introspectors, so it above can be reduced
to:
Vadim Gritsenko said:
Nicola Ken Barozzi wrote:
Unico Hommes wrote:
...
I believe that the excalibur event package lives on at d-haven [1].
Why not use that?
Or we could stick with excalibur-event, if there is nothing wrong with it.
I believe the major concern is making sure that the
Bertrand Delacretaz wrote:
Le 29 oct. 04, à 15:51, Sylvain Wallez a écrit :
Vadim Gritsenko wrote:
Bertrand Delacretaz wrote:
...
And technically in plain XPath it would be something like
//widget/foo/@bar
IIUC, JXPath has pluggable introspectors, so it above can be reduced to:
Le 29 oct. 04, à 17:20, Vadim Gritsenko a écrit :
..But we were talking about getChild(foo)...
got it now - thanks ;-)
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
Leszek Gawron said:
JXTG is very good but it lacks a way to extend it with some reusable
pieces of
code (macros).
I have been trying to make some other templating languages be usable with
cocoon but all of them are generating TEXT and in cocoon xml land this is
a
real problem. Here
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=31857.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Ok I did a quick fix and simply pass the redirect of the original context.
This seems to work...at least for me.
Carsten
-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
Sent: Friday, October 29, 2004 3:15 PM
To: Cocoon-Dev
Subject: [BUG] Redirector is null in
Hello
I really appreciate you taking the time to look through the code. I've
inlined some comments below.
On Thu, 2004-10-28 at 15:06, Sylvain Wallez wrote:
Jonas Ekstedt wrote:
On Thu, 2004-10-28 at 12:50, Reinhard Poetz wrote:
After reading it once, one question: Do you see any way
Ralph Goers wrote:
I believe that the excalibur event package lives on at
d-haven [1].
Why not use that?
Or we could stick with excalibur-event, if there is nothing
wrong with it.
I believe the major concern is making sure that the Cocoon
core only relies on solid,
Reinhard Poetz wrote:
Stefano Mazzocchi wrote:
Reinhard Poetz wrote:
More information and explanations can be found at
http://wiki.apache.org/cocoon/CocoonBlockBuilder
[not critizing, just curious] can you explain why you think that
having block/lib is going to be jar hell while lib/block is
Giacomo Pati wrote:
On Fri, 29 Oct 2004, Reinhard Poetz wrote:
Tony Collen wrote:
Do we need a new, (standardized?) or possibly even *gasp* better
templating system for Cocoon? This is where I encourage people to
dive in and give their own [RT]s and thoughts on the issue.
First, thank you for
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
XPath is a must-have when you deal with XML documents while
Jexl is mostly useless in that case but is straightforward
when you deal with JavaBeans. I also agree that understanding
the difference between ${continuation.id} and
#{$continuation/id}
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
XPath is a must-have when you deal with XML documents while Jexl is
mostly useless in that case but is straightforward when you deal with
JavaBeans. I also agree that understanding the difference between
${continuation.id}
Carsten Ziegeler wrote:
Bertrand Delacretaz wrote:
I don't think JXTG is broken now, it works well but the code
is hard to understand and having all classes in a single huge
source code file does not help.
Yupp, that is one of the problems with JXTG. It would be great if
a new solution would be
Bart Molenkamp wrote:
Maybe CRON can handle this job? Or isn't it a good idea to have the core
of Cocoon depent on CRON?
unfortunately, CRON is not a portable service across OS and we do
support silly microsoft OSs too.
--
Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
Stefano Mazzocchi wrote:
Bart Molenkamp wrote:
Maybe CRON can handle this job? Or isn't it a good idea to have the core
of Cocoon depent on CRON?
unfortunately, CRON is not a portable service across OS and we do
support silly microsoft OSs too.
We have a Cron block based on Quartz scheduler. I
Unico Hommes wrote:
Giacomo Pati wrote:
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
Giacomo Pati wrote:
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
The current implementation of our continuations manager uses the
excalibur event package for the background checker that checks for
expired
Vadim Gritsenko wrote:
Nicola Ken Barozzi wrote:
Unico Hommes wrote:
...
I believe that the excalibur event package lives on at d-haven [1].
Why not use that?
Or we could stick with excalibur-event, if there is nothing wrong with it.
Oh oh. We did this discussion with the container, I hope we
Reinhard Pÿfff6tz wrote:
--- Stefano Mazzocchi [EMAIL PROTECTED] schrieb:
Reinhard Poetz wrote:
Stefano Mazzocchi wrote:
Reinhard Poetz wrote:
More information and explanations can be found
at
http://wiki.apache.org/cocoon/CocoonBlockBuilder
[not critizing, just curious] can you
1 - 100 of 111 matches
Mail list logo
