On Mon, Apr 26, 2004 at 12:40:16AM +0200, Gianugo Rabellino wrote:
On Apr 25, 2004, at 11:18 PM, Leszek Gawron wrote:
Could anybody explain why I get ConcurrentModificationException with
this
code:
this is a known issue with the FileSource: if you look at your
context directory, you
Leszek Gawron wrote:
Could anybody explain why I get ConcurrentModificationException with this
code:
function test() {
var str = rootguid[EMAIL PROTECTED]/guidcontractor1/contractorpositionspositionabc/positionpositionabcd/positionpositionabce/position/positions/root;
var buffer = new
Bruno Dumon wrote:
On Sun, 2004-04-25 at 15:10, Sylvain Wallez wrote:
Marc Portier wrote:
snip/
Sorry for the massive commit, however when walking around the code it
only looked like the proverbial tip of the iceberg.
Sorry for the delay, but, as we say here later is better than
On Mon, Apr 26, 2004 at 09:37:10AM +0200, Sylvain Wallez wrote:
Leszek Gawron wrote:
Could anybody explain why I get ConcurrentModificationException with this
code:
function test() {
var str =
rootguid[EMAIL
Marc Portier wrote:
Sylvain Wallez wrote:
Marc Portier wrote:
snip/
Sorry for the massive commit, however when walking around the code
it only looked like the proverbial tip of the iceberg.
Sorry for the delay, but, as we say here later is better than never!
yep, thx for chiming in
-
On Mon, 2004-04-26 at 09:51, Sylvain Wallez wrote:
Bruno Dumon wrote:
On Sun, 2004-04-25 at 15:10, Sylvain Wallez wrote:
Note that I'd like also that wi:styling could be written in the definition also,
as defining the styling in the widget definition can be a productivity boost with
On Mon, 2004-04-26 at 10:43, Marc Portier wrote:
Sylvain Wallez wrote:
Marc Portier wrote:
Sylvain Wallez wrote:
- if we allow fi:styling in the definition (which is needed IMO), we
must still retain the possibility to override it in the template. The
associated logic on the
Marc Portier wrote:
The flexibility introduced by decoupling start/endSAXFragment is not
on the widget side, but on the template side: it allows to much more
easily handled nested template instructions. This has several uses:
- as of today, SAX events for container widgets must be completely
Bruno Dumon wrote:
On Mon, 2004-04-26 at 10:43, Marc Portier wrote:
Sylvain Wallez wrote:
Marc Portier wrote:
Sylvain Wallez wrote:
- if we allow fi:styling in the definition (which is needed IMO), we
must still retain the possibility to override it in the template.
On Sun, 2004-04-25 at 18:36, Upayavira wrote:
Christopher Oliver wrote:
Bruno Dumon wrote:
I'm a bit annoyed by the current status of our flowscript API's for
CForms. I'll leave the intro for what it is and just jump right into it:
Form.showForm()
===
I find that
Sylvain Wallez wrote:
Bruno Dumon wrote:
On Mon, 2004-04-26 at 10:43, Marc Portier wrote:
Sylvain Wallez wrote:
Marc Portier wrote:
Sylvain Wallez wrote:
- if we allow fi:styling in the definition (which is needed IMO),
we must still retain the possibility to override
On Mon, Apr 26, 2004 at 12:03:07PM +0200, Bruno Dumon wrote:
On Sun, 2004-04-25 at 18:36, Upayavira wrote:
Christopher Oliver wrote:
Bruno Dumon wrote:
I'm a bit annoyed by the current status of our flowscript API's for
CForms. I'll leave the intro for what it is and just jump
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=28094.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi all,
In cocoon forms we always use cocoon.sendPage to show after submit,like
this code in registration.js under samples\forms\flow:
cocoon.sendPage(registration-success-pipeline.jx, bizdata);
and then in sitemap to display it.
But if I use redirect-to in this pipeline like:
Just after submit my mail I saw an archive mail-list describe the same:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=10756461460w=2,but
nobody response.
Roy Huang
_
MSN Hotmail http://www.hotmail.com
wrote:
Just after submit my mail I saw an archive mail-list describe the same:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=10756461460w=2,but
nobody response.
Just curious, try:
map:redirect-to uri=/samples/ global=true/
See if that works.
Upayavira
I have a CachingURICoplet, basically a CForm. I
access the page with the coplet via a bookmark:
map:match pattern=subscribe
map:generate src=cocoon:/bookmark?top=4/
map:serialize type=html/
/map:match.
When I submit the form, I get re-directed to the same
page, however the url is now:
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=27484.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Il giorno 25/apr/04, alle 17:04, Christopher Oliver ha scritto:
What is the type of #{/docs} i.e. what does #{getClass(/docs)} output?
class org.apache.commons.jxpath.BasicNodeSet
What is the type of #{.}i.e.what does #{getClass(.)}output?
class org.apache.commons.jxpath.BasicNodeSet
What
Il giorno 25/apr/04, alle 13:43, Leszek Gawron ha scritto:
What about simple content#{/docs}/content?
content[EMAIL PROTECTED]/content
Ugo
On 26.04.2004 09:51, Sylvain Wallez wrote:
:-) This translation is the right one. I'm always amazed to see that
French is a foreign language for you and Marc, whose names sound so much
more frenchy that many french people's name, including mine ;-)
Isn't Sylvain *the* French name? I only met
On Mon, 2004-04-26 at 15:40, wrote:
Hi all,
In cocoon forms we always use cocoon.sendPage to show after submit,like
this code in registration.js under samples\forms\flow:
cocoon.sendPage(registration-success-pipeline.jx, bizdata);
and then in sitemap to display it.
But if I
While browsing our sources, I came across this snippet from
o.a.c..components.pipeline.AbstractProcessingPipeline:
// execute the pipeline:
this.generator.generate();
byte[] data = os.toByteArray();
I saw the following template in forms-field-styling.xsl:
!--+
| fi:booleanfield with @type 'output' : rendered as text
+--
xsl:template match=fi:booleanfield[fi:styling/@type='output']
xsl:choose
xsl:when test=fi:value = 'true'
yes
/xsl:when
The build of the current CVS head seems to be broken:
/Users/ugocei/Projects/cocoon-2.1/src/blocks/forms/test/org/apache/
cocoon/forms/datatype/FlowJXPathSelectionListTestCase.java:100:
CONTEXT_OBJECT has private access in
org.apache.cocoon.components.flow.FlowHelper
Il giorno 26/apr/04, alle 23:09, Ugo Cei ha scritto:
The build of the current CVS head seems to be broken:
I forgot to mention that it's just the test target whose build is
broken. Not that it matters less.
Ugo
Ugo Cei wrote:
The build of the current CVS head seems to be broken:
[snip]
BUILD FAILED
This is due to Sylvain's recent changes to FlowHelper.java:
-public static final String CONTEXT_OBJECT = cocoon.flow.context;
+private static final String CONTEXT_OBJECT =
On Mon, 2004-04-26 at 22:39, Ugo Cei wrote:
While browsing our sources, I came across this snippet from
o.a.c..components.pipeline.AbstractProcessingPipeline:
// execute the pipeline:
this.generator.generate();
byte[] data =
Il giorno 26/apr/04, alle 23:19, Bruno Dumon ha scritto:
The same pattern occurs at other locations also, e.g.
AbstractCachingProcessingPipeline line 246
Yes, there are four occurrences between AbstractProcessingPipeline and
AbstractCachingProcessingPipeline. I've optimized all four locally and
On Mon, 2004-04-26 at 23:09, Ugo Cei wrote:
The build of the current CVS head seems to be broken:
/Users/ugocei/Projects/cocoon-2.1/src/blocks/forms/test/org/apache/
cocoon/forms/datatype/FlowJXPathSelectionListTestCase.java:100:
CONTEXT_OBJECT has private access in
Joerg Heinicke wrote:
On 26.04.2004 09:51, Sylvain Wallez wrote:
:-) This translation is the right one. I'm always amazed to see that
French is a foreign language for you and Marc, whose names sound so
much more frenchy that many french people's name, including mine ;-)
Isn't Sylvain *the*
Ugo Cei wrote:
While browsing our sources, I came across this snippet from
o.a.c..components.pipeline.AbstractProcessingPipeline:
// execute the pipeline:
this.generator.generate();
byte[] data = os.toByteArray();
Bruno Dumon wrote:
I saw the following template in forms-field-styling.xsl:
!--+
| fi:booleanfield with @type 'output' : rendered as text
+--
xsl:template match=fi:booleanfield[fi:styling/@type='output']
xsl:choose
xsl:when test=fi:value = 'true'
yes
/xsl:when
Il giorno 26/apr/04, alle 23:31, Bruno Dumon ha scritto:
fix it :-) Just did so.
Thanks a lot,
Ugo
On 26.04.2004 22:58, Bruno Dumon wrote:
I saw the following template in forms-field-styling.xsl:
!--+
| fi:booleanfield with @type 'output' : rendered as text
+--
xsl:template match=fi:booleanfield[fi:styling/@type='output']
xsl:choose
xsl:when test=fi:value = 'true'
Joerg Heinicke wrote:
On 26.04.2004 22:58, Bruno Dumon wrote:
I saw the following template in forms-field-styling.xsl:
!--+
| fi:booleanfield with @type 'output' : rendered as text
+--
xsl:template match=fi:booleanfield[fi:styling/@type='output']
xsl:choose
xsl:when
On 26.04.2004 23:43, Sylvain Wallez wrote:
They would also be reset after request.
These stylings make only sense if the form widget values are not
evaluated. I can imagine a confirmation page, where just the submit
widget (ok vs. cancel) is evaluated.
BooleanField is special as no parameter
On Tue, Apr 27, 2004 at 12:05:58AM +0200, Joerg Heinicke wrote:
On 26.04.2004 23:43, Sylvain Wallez wrote:
I would like to see a more explicite setting for this behaviour - and
also supporting all widget types. We already talked a bit about a
direction=save|load|both for the field definition
I have a situation where I wanted to throw an exception from an action and
thereby kill the pipeline, but this does not seem to be working.
Instead, the action seems to just fail and follow the alternate path through
the pipeline, rather than calling the error handler. The exception does seem
I have a situation where I wanted to throw an exception from an action and
thereby kill the pipeline, but this does not seem to be working.
Instead, the action seems to just fail and follow the alternate path through
the pipeline, rather than calling the error handler. The exception does
.. Original Message ...
On Mon, 26 Apr 2004 00:56:51 +0200 Torsten Curdt [EMAIL PROTECTED] wrote:
A very late reminder!!
Date: Sunday 25 2004.
Time: 14:00 UTC
...to late for me. Is there a log online?
What are the results of the discussion?
cheers
--
Torsten
A log should be at
41 matches
Mail list logo
