RE: cvs commit: cocoon-2.1/tools/src blocks-build.xsl

Stephan Michels wrote > > Ehm, are you sure that this works? The xconf's from the different > > blocks have to be applied in the correct order (in the > order of their > > dependencies). If you all apply at once this is imho not > guarenteed, > > right? > > Now it should work. I rewrote the X

Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)

Bertrand Delacretaz wrote: Le Jeudi, 11 mars 2004, à 23:06 Europe/Zurich, Paul Russell a écrit : On 10 Mar 2004, at 19:51, Steven Noels wrote: (OT for the non-ASF folks:) You seem to suggest that inclusion of non-ASL-licensed library dependencies inside ASF distributions should be deprecated,

Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)

Le Jeudi, 11 mars 2004, à 23:06 Europe/Zurich, Paul Russell a écrit : On 10 Mar 2004, at 19:51, Steven Noels wrote: (OT for the non-ASF folks:) You seem to suggest that inclusion of non-ASL-licensed library dependencies inside ASF distributions should be deprecated, favoring a CPAN or FreeBSD po

Re: [CForms] Support for multipe unique-row-id in Repeater

On 11.03.2004 17:31, Marc Portier wrote: All together we are at: yep, sounds like the best we have ATM So, I implemented this myself. To be honest, I'm proud of this work. Not only that I got it working, I also had the feeling I know what I'm doing :) Ok, it to

Re: LuceneIndexContentHandler

On 12.03.2004 00:18, Vadim Gritsenko wrote: Yes, note that I wrote "addition" above - in addition to your suggestion: Sorry, missed that obviously. Joerg

Re: LuceneIndexContentHandler

On 11.03.2004 20:50, Joerg Heinicke wrote: Replace the startElements in your sample with endElements and it won't work. But adding if(flag) like above additionally to endElement should fix this. Did we get it now? :) I have it done like the following characters flag = true endElement if(

Re: LuceneIndexContentHandler

Joerg Heinicke wrote: On 11.03.2004 13:23, Vadim Gritsenko wrote: startElement a character 'key' startElement b character 'word' Will become "keyword" instead of "key word". No, this won't work, again :-) Addition of startElement: if (flag) x.append(' '); flag = false; Sh

Re: cvs commit: cocoon-2.1/src/blocks/cron/java/org/apache/cocoon/environment/background BackgroundEnvironment.java

On 11.03.2004 22:57, Sylvain Wallez wrote: quoting Eclipse: "The private field QuartzJobScheduler.jobEnvironment is never read locally." Is it needed? Well, if Eclipse says no, I guess it's right ;-) Seriously, this refactoring went through several iterations and the location of the environmen

Re: Cocoon's Rhino+continuations fork

On 10 Mar 2004, at 19:51, Steven Noels wrote: (OT for the non-ASF folks:) You seem to suggest that inclusion of non-ASL-licensed library dependencies inside ASF distributions should be deprecated, favoring a CPAN or FreeBSD ports -like mechanism instead. This will definitely lower the ease of us

Re: cvs commit: cocoon-2.1/src/blocks/cron/java/org/apache/cocoon/environment/background BackgroundEnvironment.java

Joerg Heinicke wrote: On 11.03.2004 16:38, [EMAIL PROTECTED] wrote: sylvain 2004/03/11 07:38:31 Modified:src/blocks/cron/java/org/apache/cocoon/components/cron QuartzJobScheduler.java TestCronJob.java QuartzJobExecutor.java

Re: cvs commit: cocoon-2.1/tools/targets upgrade-build.xml

[EMAIL PROTECTED] wrote: joerg 2004/03/11 11:42:32 Modified:tools/targets upgrade-build.xml Log: a little mistake Revision ChangesPath 1.4 +1 -1 cocoon-2.1/tools/targets/upgrade-build.xml Index: upgrade-build.xml ===

Re: XSP block status

On Mar 11, 2004, at 8:35 PM, Reinhard Pötz wrote: leo leonid wrote: On Mar 11, 2004, at 6:50 PM, Reinhard Pötz wrote: leo leonid wrote: Hi, I just updated my projects from woody to cocoon forms (absolutely painless, BTW). How did you do the upgrade? I used your ant task ($COCOON_HOME/build

Re: LuceneIndexContentHandler

On 11.03.2004 13:23, Vadim Gritsenko wrote: startElement a character 'key' startElement b character 'word' Will become "keyword" instead of "key word". No, this won't work, again :-) Addition of startElement: if (flag) x.append(' '); flag = false; Should fix it, shouldn't it? This

Re: XSP block status

leo leonid wrote: On Mar 11, 2004, at 6:50 PM, Reinhard Pötz wrote: leo leonid wrote: Hi, I just updated my projects from woody to cocoon forms (absolutely painless, BTW). How did you do the upgrade? I used your ant task ($COCOON_HOME/build.sh woody2CocoonForms-renaming). It did the job qu

Re: cvs commit: cocoon-2.1/src/blocks/forms/samples/resources forms-field-styling.xsl

Joerg Heinicke wrote: On 11.03.2004 20:18, [EMAIL PROTECTED] wrote: Modified:src/blocks/forms/samples/resources forms-field-styling.xsl Log: add text attribute (any reason why it is missing?) I guess not, it's just the default. Joerg Okay, I added it because I want to use it to be

Re: cvs commit: cocoon-2.1/src/blocks/forms/samples/resources forms-field-styling.xsl

On 11.03.2004 20:18, [EMAIL PROTECTED] wrote: Modified:src/blocks/forms/samples/resources forms-field-styling.xsl Log: add text attribute (any reason why it is missing?) I guess not, it's just the default. Joerg

Re: XSP block status

On Mar 11, 2004, at 6:50 PM, Reinhard Pötz wrote: leo leonid wrote: Hi, I just updated my projects from woody to cocoon forms (absolutely painless, BTW). How did you do the upgrade? I used your ant task ($COCOON_HOME/build.sh woody2CocoonForms-renaming). It did the job quite perfectly. Only

Re: cvs commit: cocoon-2.1/src/blocks/cron/java/org/apache/cocoon/environment/background BackgroundEnvironment.java

On 11.03.2004 16:38, [EMAIL PROTECTED] wrote: sylvain 2004/03/11 07:38:31 Modified:src/blocks/cron/java/org/apache/cocoon/components/cron QuartzJobScheduler.java TestCronJob.java QuartzJobExecutor.java AbstractPipel

Re: XSP block status

Am Mi, den 10.03.2004 schrieb Unico Hommes um 19:24: > There remain a few issues that need resolving. > > - InputModuleAction had to move along with xsp because it has a > dependency on some xsp helper class. This is unfortunate and maybe > unnecessary. Perhaps someone with more knowledge about

Re: XSP block status

Am Do, den 11.03.2004 schrieb leo leonid um 18:24: > Hi, > > I just updated my projects from woody to cocoon forms (absolutely > painless, BTW). I see it similar, a simple s/woody/forms/g, and most of the work is done. I doesn't see a real need to keep the woody block, but anyway... > Unfortun

Re: XSP block status

leo leonid wrote: Hi, I just updated my projects from woody to cocoon forms (absolutely painless, BTW). How did you do the upgrade? -- Reinhard

DO NOT REPLY [Bug 26753] - [PATCH] Persistent store or cache corruption?

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 26753] - [PATCH] Persistent store or cache corruption?

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: XSP block status

Hi, I just updated my projects from woody to cocoon forms (absolutely painless, BTW). Unfortunately now most of my projects are broken anyhow, because they use XSP (ESQL), and I was not aware of the XSP refactoring going on :( Was it just a bad moment for CVS-update or does the move of XSP to

Re: [CForms] Support for multipe unique-row-id in Repeater

Joerg Heinicke wrote: On 05.03.2004 17:45, Marc Portier wrote: Yes, I only see that wb:unique-row (grouped by type: unique or not unique) is outside of wb:on-bind (grouped by event: on-bind, on-insert, on-delete) though it is executed also at on-bind event. yes, but do you find that surprisi

RE: cvs commit: cocoon-2.1/tools/src blocks-build.xsl

Am Do, den 11.03.2004 schrieb Carsten Ziegeler um 16:48: > [EMAIL PROTECTED] wrote: > > > > Modified:tools/src blocks-build.xsl > > Log: > > Apply all xconf file in one shoot. > > > Ehm, are you sure that this works? The xconf's from the different > blocks have to be applied in the co

RE: cvs commit: cocoon-2.1/tools/src blocks-build.xsl

[EMAIL PROTECTED] wrote: > > Modified:tools/src blocks-build.xsl > Log: > Apply all xconf file in one shoot. > Ehm, are you sure that this works? The xconf's from the different blocks have to be applied in the correct order (in the order of their dependencies). If you all apply at onc

Re: ExtendedResourceExistsAction ?

Stephan Michels apache.org> writes: > Hi, > > some samples require the ExtendedResourceExistsAction. Where went > this action? > Marged with ResourceExistsAction? I would assume this from the commit message: http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/scratchpad/ java/org/apache/co

ExtendedResourceExistsAction ?

Hi, some samples require the ExtendedResourceExistsAction. Where went this action? Marged with ResourceExistsAction? Thanks, Stephan.

DO NOT REPLY [Bug 27604] - Cocoon Forms stylesheet reports error if xsltc used

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: [cforms] selection list binding

Ugo Cei cbim.it> writes: > > Do you have a solution for the 'non-value' entry in the items collection? I > > use the selection list as filter for the list pages. And I want to provide an > > option to do no filtering by this selection list. > > I usually do the following: > > var collecti

Re: [cforms] selection list binding

Joerg Heinicke wrote: Do you have a solution for the 'non-value' entry in the items collection? I use the selection list as filter for the list pages. And I want to provide an option to do no filtering by this selection list. I usually do the following: var collection = getSomeCollection()

DO NOT REPLY [Bug 27604] New: - Cocoon Forms stylesheet reports error if xsltc used

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: [Vote] Change internal redirect handling

Vadim Gritsenko wrote: Why (a), (b), or (c) ? There is always option of (d): d) Make it configurable on handle-errors element of the called pipeline. This way, behavior of redirect-to does not need to be changed, and this feature is more useful in general - especially in "portlets". Or is th

Re: [cforms] selection list binding

Ugo Cei cbim.it> writes: > > Ok, let me clarify. I think I do nothing unusual. Yes, I have a form > > with a simple dynamic selection list. And I do the binding against a bean. > > This is what I do all the time. I thought so too :) > > There are two known ways to set the selection list dynam

Re: Cocoon's Rhino+continuations fork

On 09 Mar 2004, at 22:48, Brendan Eich wrote: (some parts snipped - just trying to bring this to a solution suggestion) But I don't like this, of course. It wasn't our intention to fork, we just ended up using a fork written by a Cocoon committer outside the Cocoon project. Forks are bad bus

DO NOT REPLY [Bug 27602] - Small Improvment for AbstractReader

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 27602] New: - Small Improvment for AbstractReader

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: First pass at Apache Wiki conversion

Joerg Heinicke wrote: http://wiki.apache.org/cocoon/FAQs: The list at the beginning is broken. The numbering of the sections is also strange in the file: "1. 1. Meta-FAQ" instead of "1. Meta-FAQ". Fixed. I strip 1. from a title if I find it, as Moin adds it back. Steven Noels wrote: http://wik

RE: [Vote] Change internal redirect handling

Vadim Gritsenko wrote: > >> > >> So, we have three choices to change this: > >> > >> a) Make an internal redirect a real forward (This is an > >> incompatible change) > >> > >> b) Make it configurable on the uri, like >> uri="cocoon://some-pipeline?cocoon:forward=true"/> > >> > >> c) Make it con

Re: [RT] Forwarding of internal pipeline calls

Carsten Ziegeler wrote: Vadim Gritsenko wrote: ... I'd prefer not to pollute request parameters with internal cocoon stuff. This reminds me of recently fixed header action which was iterating over sitemap parameters. Similarly, users may rely in theirs code on request parameters and itera

Re: [Vote] Change internal redirect handling

Sylvain Wallez wrote: Carsten Ziegeler wrote: As discussed recently, our internal redirects don't work the way one would usually suspect. If you do an internal redirect, like: and the called pipeline has an error, then the error handler of the calling pipeline (containing the redirect) is cal

Re: LuceneIndexContentHandler

Joerg Heinicke wrote: On 09.03.2004 13:43, Vadim Gritsenko wrote: Yes, I see your objection - and asked for them already in the bug http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25934 ;) So what are the practical use cases this might occure? Maybe it's only a theoretical problem depending

DO NOT REPLY [Bug 25110] - [Roadmap] CocoonForms - release 1.0

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 27601] New: - unified repeater binding syntax

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 25110] - [Roadmap] CocoonForms - release 1.0

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 27600] New: - syntax for unique rows in repeater binding

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 25110] - [Roadmap] CocoonForms - release 1.0

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 27599] New: - FormTemplateTransformer eats elements in default namespace

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 25110] - [Roadmap] CocoonForms - release 1.0

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 27598] New: - add the possibility to prevent widgets from reading value from request

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 27188] - CocoonPortlet default-encoding

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 26792] - excalibur-xmlutil, o.a.e.x.i.JaxpParser, unreleased EntityResolver

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: [cforms] selection list binding

Joerg Heinicke wrote: Ok, let me clarify. I think I do nothing unusual. Yes, I have a form with a simple dynamic selection list. And I do the binding against a bean. This is what I do all the time. There are two known ways to set the selection list dynamically: setSelectionList(String uri) and s