David Crossley wrote:
+1 for the ability to return for subsequent processing.
I like the explicit name return-no-match.
The default should ideally be true, but does that sit okay
with back-compatibility?
No :) The default should be false.
I'm not a native speaker (obviously) and don't want
Le 31 août 04, à 08:33, Carsten Ziegeler a écrit :
David Crossley wrote:
+1 for the ability to return for subsequent processing.
I like the explicit name return-no-match.
The default should ideally be true, but does that sit okay
with back-compatibility?
No :) The default should be false.
+1, the
David Crossley wrote:
...
+1 for the ability to return for subsequent processing.
I like the explicit name return-no-match.
The fact is that it's not necessarily true that it will be only matches
that it fails to find. The contract is simply that it will continue if
no xml pipeline
if you're planning to attend to GetTogether 2004, it would be nice
if you add your name in this list:
This wouldn't perhaps be happening somewhere close to Southern California.
sigh
I didn't think so.
I've got a bunch of people who could really benefit from this - especially
a
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=24402.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
If the @passthrough attribute is to be put in the pipelines section of
the mounted sitemap, it seems easy: make the PipelinesNodeBuilder set a
passthrough variable in the PipelinesNode, and have the PipelinesNode
tell or not the last PipelineNode if it has to stop:
public void
Nicola Ken Barozzi wrote:
In any case, the best one that will seem ok to me will go in there...
after all it's the functionality we need, not the name ;-) (*)
It sure is great to see someone doing the work. The names are
important to convey true meaning, yet they do need to be easy
to type.
Nicola Ken Barozzi wrote:
If the @passthrough attribute is to be put in the pipelines section
of the mounted sitemap, it seems easy: make the PipelinesNodeBuilder
set a passthrough variable in the PipelinesNode, and have the
PipelinesNode tell or not the last PipelineNode if it has to stop:
Unico Hommes wrote:
...
What about letting MountNode catch the No pipeline matched request
exception that is thrown during processor.buildPipeline() and
processor.process() and decide whether or not to rethrow it there. Would
that work?
It could, but I'd have to check somehow that it's the
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
The passthrough information cannot be set on the processing
node, as it depends on the runtime environment (a single
sitemap can be mounted from different locations with
different values for passthrough).
IMO, the easiest way is for the mount
Sylvain Wallez wrote:
Why so? The Environment provides attributes, so why not using
them? Or is it just because that information is somehow
hidden in a HashMap ?
No, in my understanding environment has nothing to do with the
tree processor, but anyways if it's a working solution go for
There is a bug in raw-request-param module:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25102
which could be quite important for some people
at least is for me ;). Is there any chance that some
of you guys would fix it? I would do it myself, but
unfortunately I'm not a Java programmer
Guys - you are always great help for me.
I have new problem for you to help.
I need to intercept a request at the earliest possible point within the
Cocoon context.
any ideas - does the concept of interceptors exist within Cocoon.
What about using nested actions is that a possible direction? Any
Try the RequestListener
On Tue, 2004-08-31 at 15:39, Jennifer Yip wrote:
Guys - you are always great help for me.
I have new problem for you to help.
I need to intercept a request at the earliest possible point within the
Cocoon context.
any ideas - does the concept of interceptors
Hi,
I am trying to use the new JDK1.5 foreach loop in XSP, basically:
List entries = new ArrayList();
for (Map entry: entries) {
...
}
which causes the following error with the default EclipseJavaCompiler:
// start error (lines 1003-1003) Syntax error on token :, ;
expected
On Die, 2004-08-31 at 14:39 -0500, Tony Collen wrote:
There's already a bug filed against cocoon for java 1.5 compatibility.
you might want to look into that. i don't think anyone's really checked
into the actual cause of the problem yet though.
The bugs I have found are related to building
Thomas Zehetbauer wrote:
On Die, 2004-08-31 at 14:39 -0500, Tony Collen wrote:
There's already a bug filed against cocoon for java 1.5 compatibility.
you might want to look into that. i don't think anyone's really checked
into the actual cause of the problem yet though.
The bugs I have found
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=24402.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I've got a bunch of people who could really benefit from this - especially
a presentation on CForms and flow.
Uhm... shameless plug, sorry about that, but just in case:
http://www.apachecon.com/html/session-popup.html?id=1069
This is going to be a three hour session on everything Cocoon.
Also,
19 matches
Mail list logo
