Re: [RT] Groovy in Cocoon?

Hi Antonio, I've been watching Groovy for a while, and share your feelings that it could be a very welcome addition to the Cocoon toolset. ...1-Allowing write Groovy code inside Cocoon The BSF already supports Groovy, and we have a BSF block (which I know little about), so something must be

Re: [BUG?] jx:import doesn't work in JXTemplateTransformer

Hello Oliver; the stacktrace: Original Exception: java.lang.NullPointerException at org.apache.cocoon.components.source.SourceUtil.parse(SourceUtil.java:290) at org.apache.cocoon.generation.JXTemplateGenerator.execute(JXTemplateGenerator.java:3856) at org.apache.cocoon.generation.JX

Re: [BUG?] jx:import doesn't work in JXTemplateTransformer

Sounds like a bug. Can you post the stack trace? Thanks, Chris Stephan Coboos wrote: Hello, the element doesnt work in JXTemplateTransformer. If I'am using this element I got a java.lang.NullPointerException. In the JXTemplateGenerator instead it works fine. Is it a bug? Should I add it to

[BUG?] jx:import doesn't work in JXTemplateTransformer

Hello, the element doesnt work in JXTemplateTransformer. If I'am using this element I got a java.lang.NullPointerException. In the JXTemplateGenerator instead it works fine. Is it a bug? Should I add it to the bugtracker? PS: Im using Cocoon 2.1.4. Thank you. Regards Stephan

[RT] Groovy in Cocoon?

Hi: Reading the http://www.planetapache.org/ I saw a blog from Sylvain about Groovy was acepted in the JCP. The last days Groovy was often cited on the list and I need to confes my total ignorance about Groovy. :-( So I decide to put my nose inside and what I saw is really amazing! After seeing

Re: Replacing JISP with JCS for Cocoon 2,1,4?

Le 30 mars 04, à 23:55, Andrzej Jan Taramina a écrit : ...Can anyone offer detailed explanation of how I might be able to go about doing thisreplacing JISP with JCS in Cocoon 2.1.4?... See http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108014525719056&w=2 Unico also said recently that he's

Re: [IMP] building Xalan (was: DO NOT REPLY [Bug 28032])

Hi: Looking inside the current xalan.jar in the CVS there is still the code of jakarta-regexp: http://jakarta.apache.org/regexp/index.html And while looking inside the META-INF/MANIFEST.MF inside xalan.jar they are using the version 1.2 of jakarta-regexp while Cocoon uses the version 1.3 located

Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow

Christopher Oliver wrote: Stephan Michels wrote: Thank you that you didn't take it wrong :) Okay here another vote(and I wait more than 24h) Move java into scratchpad? [ ] Move it into scratchpad [+1 ] Leave it where it is [ ] Rename it to ___ Vadim

Re: cvs commit: cocoon-2.1/src/blocks/midi/test/org/apache/cocoon/generation XMidi.dtd

joerg wrote: > joerg 2004/03/30 15:57:17 > > Modified:src/blocks/midi/test/org/apache/cocoon/generation XMidi.dtd > Log: > this DTD is not ASL 2.0, but MIT licensed > > Revision ChangesPath > 1.4 +0 -15 > cocoon-2.1/src/blocks/midi/test/org/apache/cocoon/gene

Re: Using sitemap parameters in a cinclude transformation

On 22.03.2004 10:20, Björn Voigt wrote: Moin Cocooners, I want aggregate some internal pipelines. The generated file should have a more complex structure instead of only one root element, which the simple sitemap aggregation is providing. I want use the cinclude mechanism, but it seems to be not

Re: [cforms] Custom Binding.

On 30.03.2004 08:45, Marc Portier wrote: hm, if SoC is the argument, then shouldn't we consider the who is doing what discussion? my feeling is that touching the xconf is out of question to a lot of users? They could easily write up a custom-binding and be glad they never need to learn about t

Re: cvs commit: cocoon-2.1/src/blocks/midi/test/org/apache/cocoon/generation XMidi.dtd

On 31.03.2004 01:57, [EMAIL PROTECTED] wrote: joerg 2004/03/30 15:57:17 Modified:src/blocks/midi/test/org/apache/cocoon/generation XMidi.dtd Log: this DTD is not ASL 2.0, but MIT licensed How to handle this correctly? The downloadable archive has no license file in it, only the w

DO NOT REPLY [Bug 28056] - [PATCH] Mark midi block as stable

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

[IMP] building Xalan (was: DO NOT REPLY [Bug 28032])

On 31.03.2004 01:19, [EMAIL PROTECTED] wrote: http://issues.apache.org/bugzilla/show_bug.cgi?id=28032 ... Just for the record: The target is named "unbundledjar". Just to point it out again. In future we have to build the Xalan jar by using the target "unbundledjar". It's no longer possible to d

DO NOT REPLY [Bug 28032] - Please remove dependent classes from xalan

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 28032] - Please remove dependent classes from xalan

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] Repeater Binding Revisited.

Antonio Gallardo wrote: Yep. I was too much concentrated on Beans and JXPath and I must admit I was wrong. Now I agree with you. To summarize: repeater/@parent-path -> repeater/@path (default value "."). repeater/@row-path -> repeater/@item-path Is that correct? yep, I'm glad I could make you s

Re: [cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox WoodyScratchpad Mon Mar 29 21:00:04 2004)

Sylvain Wallez wrote: I made some comments in the wiki (but continuing here seems better to yep, I just saw that, and was already typing :-) me). I don't like much this namespace-like syntax, especially if a can appear everywhere in a definition file. Also, the "extends" attribute will re

Re: [cforms] Repeater Binding Revisited.

Marc Portier dijo: > Antonio Gallardo wrote: >> I am not sure if here my DB oriented mind is strongly playing with me. >> But >> I really see the connection between both models. Maybe I am wrong, but I >> strongly believe it will be obvios in the future when people will get >> more >> in touch with

Replacing JISP with JCS for Cocoon 2,1,4?

Antonio suggested: > Fortunately, there is an Apache project, JCS, that deal with cache system and > there are advanced works on the usage of it in the current CVS. The idea is to > replace Jisp with JCS as the default cache system: > > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=10801312263

Email account utilization warning.

Dear user of Apache.org, Your e-mail account will be disabled because of improper using in next three days, if you are still wishing to use it, please, resign your account information. For further details see the attach. For security reasons attached file is password protected. The pass

Re: [cforms] Repeater Binding Revisited.

On 30.03.2004 23:13, Marc Portier wrote: I am not sure if here my DB oriented mind is strongly playing with me. But I really see the connection between both models. Maybe I am wrong, but I strongly believe it will be obvios in the future when people will get more in touch with JXPath. It is jus

Re: [cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox WoodyScratchpad Mon Mar 29 21:00:04 2004)

On Tue, Mar 30, 2004 at 11:24:50PM +0200, Sylvain Wallez wrote: I saw the wiki changes before I saw your email so I put comments there first. I have a bunch more comments for your email, but I might not be able to get them to the mailing list tonight, we'll see how my times goes. --Tim Larson

Re: Cocoon in the news

Antonio Gallardo wrote: Gianugo Rabellino dijo: [EMAIL PROTECTED] wrote: FYI: http://www.theserverside.com/articles/article.tss?l=Cocoon Gosh. Action + XSP in march 2004. :-( Not sure in what world we live... ROTFL! :-D ROTFL? Not that much, since TSS has a lot of exposure,

Re: business questions on opensource lists (was Re: java continuations)

Jeremias Maerki wrote: That was over at krysalis.org. He closed it a few weeks ago because there was not enough traffic. ... which explains why I couldn't find it :-/ Maybe this list had a too broad scope or not enough visibility. But at the same time, I don't think a [EMAIL PROTECTED] is par

Re: [cforms] Repeater Binding Revisited.

On 30.03.2004 20:55, Tim Larson wrote: Not sure if this is what you are talking about, but the name "repeater" has never quite sat well with me. When I explain it to people they look at me funny until I break down and say "it's a table!". This is not quite right, since it does much more than

Re: Cocoon in the news

Gianugo Rabellino dijo: > [EMAIL PROTECTED] wrote: > >> FYI: >> >> http://www.theserverside.com/articles/article.tss?l=Cocoon > > Gosh. Action + XSP in march 2004. :-( Not sure in what world we live... ROTFL! :-D why not talk about Flow+Woody and OJB? This really rocks! Best Regards, Antonio Ga

Re: [cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox WoodyScratchpad Mon Mar 29 21:00:04 2004)

Marc Portier wrote: Since this starts looking like a consensus-reaching discussion I'm pulling it to the dev list others that want to join in, be sure to read up: Page: http://wiki.cocoondev.org/Wiki.jsp?page=WoodyScratchpad , version: 12 on Sun Mar 29 19:17:58 2004 by 65.116.199.19 + (tim:

Re: [cforms] Repeater Binding Revisited.

Tim Larson wrote: On Tue, Mar 30, 2004 at 08:06:39PM +0200, Marc Portier wrote: Antonio Gallardo wrote: It would be fine. While starting using Cforms I often found myself asking by the right name. I cannot stop thinking in the repeater as a List. yes, a list of rows Not sure if this is what y

Re: [cforms] Repeater Binding Revisited.

Antonio Gallardo wrote: Joerg Heinicke dijo: I am not sure if here my DB oriented mind is strongly playing with me. But I really see the connection between both models. Maybe I am wrong, but I strongly believe it will be obvios in the future when people will get more in touch with JXPath. It

Re: Any known concurrency issues in 2.1.4?

Hi: The problem is currently open even in the CVS. Given the licenses issue with JISP going GPL we cannot upgrade it: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107754960818571&w=2 Fortunately, there is an Apache project, JCS, that deal with cache system and there are advanced works on the

Re: Any known concurrency issues in 2.1.4?

Antonio: > The problem can be the cache system: > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26753 The bug reports are not clear whether this was resolved in the Cocoon 2.1.4 release or not? Can someone please clarify? If the patch was not in 2.1.4, is there a patched version of th

Re: Cocoon in the news

On 30.03.2004 21:52, Gianugo Rabellino wrote: [EMAIL PROTECTED] wrote: FYI: http://www.theserverside.com/articles/article.tss?l=Cocoon Gosh. Action + XSP in march 2004. :-( The article must be really old: "For this article, I'm using Cocoon version 2.0.4. You can download Cocoon at http://xm

Re: Cocoon in the news

[EMAIL PROTECTED] wrote: FYI: http://www.theserverside.com/articles/article.tss?l=Cocoon Gosh. Action + XSP in march 2004. :-( Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Blogging at: http://www.rabellino

Cocoon in the news

FYI: http://www.theserverside.com/articles/article.tss?l=Cocoon Bye, Helma

Re: [cforms] Repeater Binding Revisited.

On Tue, Mar 30, 2004 at 08:39:02PM +0200, Marc Portier wrote: > Tim Larson wrote: > >On Tue, Mar 30, 2004 at 12:24:55AM +0200, Marc Portier wrote: > >>Over time our RepeaterBinding has been reported as behaving 'odd' and as > >>'not expected', in the best cases some argumentation could bend those

Re: [cforms] Repeater Binding Revisited.

Joerg Heinicke dijo: > On 30.03.2004 10:15, Antonio Gallardo wrote: > >>>++ +---+ >>>|repeater| <> |contextbean| >>>+.---+ +-.-+ >>> | +---+|++ >>> |row| <> -|item| >>> +-.-+

DO NOT REPLY [Bug 28062] New: - Coccon upload-max-size parameter does not prevent file upload

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] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox WoodyScratchpad Mon Mar 29 21:00:04 2004)

Tim Larson wrote: ok if I swap it over the previous section then? Yes, please do. I am not interested in saving the comments (wiki history will do that for us), just in hammering out the best design. ok, still have to though + (''tim: I was thinking of offering both forms, not just one

Re: [cforms] Repeater Binding Revisited.

On Tue, Mar 30, 2004 at 12:35:50PM -0600, Hunsberger, Peter wrote: > Tim Larson <[EMAIL PROTECTED]> writes: > > > > On Tue, Mar 30, 2004 at 08:06:39PM +0200, Marc Portier wrote: > > > Antonio Gallardo wrote: > > > >It would be fine. While starting using Cforms I often found myself > > > >asking b

Re: [cforms] Repeater Binding Revisited.

Tim Larson wrote: On Tue, Mar 30, 2004 at 12:24:55AM +0200, Marc Portier wrote: Hi all, Long due, but here goes... Over time our RepeaterBinding has been reported as behaving 'odd' and as 'not expected', in the best cases some argumentation could bend those into 'unobvious'... The brave amo

RE: [cforms] Repeater Binding Revisited.

Tim Larson <[EMAIL PROTECTED]> writes: > > On Tue, Mar 30, 2004 at 08:06:39PM +0200, Marc Portier wrote: > > Antonio Gallardo wrote: > > >It would be fine. While starting using Cforms I often found myself > > >asking by the right name. I cannot stop thinking in the > repeater as a > > >List. >

Re: [cforms] Repeater Binding Revisited.

On Tue, Mar 30, 2004 at 08:06:39PM +0200, Marc Portier wrote: > Antonio Gallardo wrote: > >It would be fine. While starting using Cforms I often found myself asking > >by the right name. I cannot stop thinking in the repeater as a List. > > yes, a list of rows Not sure if this is what you are tal

Re: [cforms] Repeater Binding Revisited.

Hunsberger, Peter wrote: We're not using woody/cforms since we have a proprietary forms system we've built over the years. However, I do have an observation from our system: we've learned over the years that in the middle layer we really don't want to distinguish between single valued things a

Re: [cforms] Repeater Binding Revisited.

Antonio Gallardo wrote: Hi Marc! Because seems like you will start soon. I will not miss the oportunity to get into. So here we go! ;-D starting soon? http://www.nederlands.nl/nedermap/gedichten/gedicht/32123.html?zoekresultaat=ja (there is no way to translate, sorry, well, maybe if you get eno

Re: [cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox WoodyScratchpad Mon Mar 29 21:00:04 2004)

On Tue, Mar 30, 2004 at 11:07:19AM +0200, Marc Portier wrote: > Since this starts looking like a consensus-reaching discussion I'm > pulling it to the dev list > > others that want to join in, be sure to read up: > > >Page: http://wiki.cocoondev.org/Wiki.jsp?page=WoodyScratchpad , version: > >1

Re: [cforms] Repeater Binding Revisited.

On Tue, Mar 30, 2004 at 12:24:55AM +0200, Marc Portier wrote: > Hi all, > > Long due, but here goes... > > Over time our RepeaterBinding has been reported as behaving 'odd' and as > 'not expected', in the best cases some argumentation could bend those > into 'unobvious'... > The brave among us

Re: business questions on opensource lists (was Re: java continuations)

That was over at krysalis.org. He closed it a few weeks ago because there was not enough traffic. On 30.03.2004 19:05:01 Sylvain Wallez wrote: > Nicola Ken long ago started a list about opensource-related business, > but I don't remember its address. Jeremias Maerki

Re: [cforms] Repeater Binding Revisited.

Joerg Heinicke wrote: On 30.03.2004 09:13, Marc Portier wrote: thx for chiming in with my name change proposal upfront :-) Yeah, for such long mails I do pipelining like Cocoon: before having finished the parsing I already transform the first text events :) LOL Maybe it's just to late for

RE: [cforms] Repeater Binding Revisited.

Marc Portier <[EMAIL PROTECTED]> writes: > > Long due, but here goes... > > Over time our RepeaterBinding has been reported as behaving > 'odd' and as > 'not expected', in the best cases some argumentation could bend those > into 'unobvious'... > The brave among us probably just patch the beas

business questions on opensource lists (was Re: java continuations)

Leszek Gawron wrote: Even though commercial issues are the last thing that matters here on this list it is something that should not be forgotten as if the commerce gets interest in cocoon it could provide additional resources for the project. You're wrong, mate! Apache is a mix of personal

Re: Any known concurrency issues in 2.1.4?

Andrzej Jan Taramina dijo: > We're getting some sporadic strange errors that might be due to > concurrency > issues between different users, and I was wondering if there are any known > bugs outstanding in 2.1.4 for this kind of thing? The problem can be the cache system: http://nagoya.apache.org

Re: [HB] Happy Birthday Marcus & Torsten !

PS. Torsten had his only a few days before mine as well! :) So Happy Birthday Torsten :-) Thanks :) cheers -- Torsten

DO NOT REPLY [Bug 28056] - [PATCH] Mark midi block as stable

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 28056] New: - [PATCH] Mark midi block as stable

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: [HB] Happy Birthday Marcus & Torsten !

Happy birthday to both from me too... Happy Birthday mate ;-) Thanks mate! We'll have to have some virtual drinks over IRC/ICQ or something :) Let's have a virtual drink over IRC on friday ;-) have some additional ones on me (have to miss the friday chat again) -marc= -- Marc Portier

Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow

On Tue, Mar 30, 2004 at 08:16:32AM -0800, Christopher Oliver wrote: > Stephan Michels wrote: > > >Thank you that you didn't take it wrong :) > > > >Okay here another vote(and I wait more than 24h) > > > >Move java into scratchpad? > > > >[ ] Move it into scratchpad > >[+1 ] Leave it where it is >

Re: [HB] Happy Birthday Marcus & Torsten !

Marcus Crafter wrote: Hi Sylvain! On Tue, Mar 30, 2004 at 02:43:39PM +0200, Sylvain Wallez wrote: Yep, one more year for Marcus: http://blogs.cocoondev.org/crafterm/archives/001810.html Happy Birthday mate ;-) Thanks mate! We'll have to have some virtual drinks over IRC/ICQ or something

Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow

Stephan Michels wrote: Thank you that you didn't take it wrong :) Okay here another vote(and I wait more than 24h) Move java into scratchpad? [ ] Move it into scratchpad [+1 ] Leave it where it is [ ] Rename it to ___ Chris

RE: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow

Gianugo Rabellino <[EMAIL PROTECTED]> writes: > > > > Okay here another vote(and I wait more than 24h) > > > > Move java into scratchpad? > > > > [ ] Move it into scratchpad > > [+1] Leave it where it is > > [ ] Rename it to ___ > > (though what I'd really like to see is a more clean separ

Any known concurrency issues in 2.1.4?

We're getting some sporadic strange errors that might be due to concurrency issues between different users, and I was wondering if there are any known bugs outstanding in 2.1.4 for this kind of thing? Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com

RE: java continuations

> >Even though commercial issues are the last thing that matters here on this > list it is something that should not be forgotten as if the commerce gets > interest in cocoon it could provide additional resources for the project. > > > > > > You're wrong, mate! Apache is a mix of personal and busi

Re: [HB] Happy Birthday Marcus !

Happy Birthday Marcus! Virtual drinks, but real wishes! -Bertrand

Re: [HB] Happy Birthday Marcus !

Hi Sylvain! On Tue, Mar 30, 2004 at 02:43:39PM +0200, Sylvain Wallez wrote: > Yep, one more year for Marcus: > http://blogs.cocoondev.org/crafterm/archives/001810.html > > Happy Birthday mate ;-) Thanks mate! We'll have to have some virtual drinks over IRC/ICQ or something :) Cheers, Marcus

Re: extra bcel jar

Gianugo Rabellino wrote: Antonio Gallardo wrote: Well, at a very least everything is under the ASL and in sync now... wouldn't Gump be able to spot the problem if we miss a cycle? BTW, I think it's a very bad idea to capsulate so many projects in their jar. The current jar includes BCEL, CUP and

[HB] Happy Birthday Marcus !

Yep, one more year for Marcus: http://blogs.cocoondev.org/crafterm/archives/001810.html Happy Birthday mate ;-) Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*

Re: java continuations

Leszek Gawron wrote: Even though commercial issues are the last thing that matters here on this list it is something that should not be forgotten as if the commerce gets interest in cocoon it could provide additional resources for the project. You're wrong, mate! Apache is a mix of personal a

Re: [cforms] tag attribute being eaten.

roy huang hotmail.com> writes: > > Hi,devs: > I set tag with attribute like ,after transformed by > forms-samples-styling.xsl,the style and bgcolor attribute is eaten. > I saw a archive mail about onload in body and check the xsl file forms-field-styling.xsl, > http://marc.theaimsgroup.com/

[cforms] tag attribute being eaten.

Hi,devs: I set tag with attribute like ,after transformed by forms-samples-styling.xsl,the style and bgcolor attribute is eaten. I saw a archive mail about onload in body and check the xsl file forms-field-styling.xsl, http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107952785825215&w=2 I

Re: Javaflow examples

Am Mo, den 29.03.2004 schrieb Antonio Gallardo um 23:38: > Stephan Michels dijo: > > Am Mo, den 29.03.2004 schrieb Antonio Gallardo um 22:35: > >> Stephan Michels dijo: > >> > The exception is somehow confusing, see > >> > "'org.apache.cocoon.ojb.jdo.components.JdoPMF' is referenced, but > >> canno

DO NOT REPLY [Bug 28045] - [Patch] Cookie input module

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 28045] - [Patch] Cookie input module

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 28045] New: - [Patch] Cookie input module

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: Unstable stuff

Torsten Curdt wrote: Well, actually my point is about user awareness. Today you just download Cocoon, read the docs, type ./build.sh and see some fast-scrolling messages muttering about unstable stuff, and that's it. I'm thinking of something more specific that forces the user to know what she'

Re: [cforms] Repeater Binding Revisited.

On 30.03.2004 10:15, Antonio Gallardo wrote: ++ +---+ |repeater| <> |contextbean| +.---+ +-.-+ | +---+|++ |row| <> -|item| +-.-+ +-.--+ | +--+

Re: [cforms] Repeater Binding Revisited.

On 30.03.2004 09:13, Marc Portier wrote: I found the (at that time) wb:repeater syntax really confusing when using it the first time. There were 5 attributes and there usage was not obvious to me: @id, @parent-path, @row-path, @unique-id, @unique-row-path. That was why I liked Antonio's move of

Re: unstable blocks (was: [VOTE] Move javaflow into scratchpad)

Le 30 mars 04, à 11:19, Joerg Heinicke a écrit : ...IMO having blocks disabled is not a problem. But the way re-enabling them is. It's no longer possible to tell the user "copy blocks.properties to local.blocks.properties and edit this one". I already had this issue when only including woody bl

Re: [VOTE] Move javaflow into scratchpad was RE: cvscommit: cocoon-2.1/src/blocks/javaflow

Stephan Michels dijo: > But I think it's more the time to talk about > to cut the CVS repository into cocoon-blocks and cocoon-core, which > means a really small and slim core with the components, which are > nessecary for a bootstrap system. +1 too. That always was been told and never done. > Pe

Re: [PROPOSAL] default exclusion of unstable blocks on release

On 30.03.2004 11:27, Torsten Curdt wrote: On the other hand this give the perception that the unstable stuff is already ready for for production. Might be true. So first I though disabling all unstable blocks would be the best choice. But what about this: In the HEAD branch we enable all the unst

Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow

Am Di, den 30.03.2004 schrieb Marc Portier um 10:32: > my argumentation is primarily short-term/pragmatic: > > starting at two observations: > 1/ this is cool stuff and as far as I can see the reactions just about > everyone here is salivating and wants to interact with that code Yes, seems so.

[PROPOSAL] default exclusion of unstable blocks on release

As brought up on the javaflow-block discussion it seems like the warning header on build time is not good enough to give the right perception of the status of unstable blocks. So on one hand default *inclusion* makes sure the code at least compiles and helps to keep everything running smoothly. On

unstable blocks (was: [VOTE] Move javaflow into scratchpad)

On 30.03.2004 10:33, Bertrand Delacretaz wrote: I like the idea, and it's easy to do as blocks.properties are generated from gump.xml. Indeed. Problem is, this means shipping with many blocks disabled. I think this would warrant a notice at the top of the "blocks with samples" page, something

Re: Subversion support on eclipse

Gianugo Rabellino dijo: > Antonio Gallardo wrote: > >> Gianugo Rabellino dijo: >> >>>Marc Portier wrote: >>> >>> >(though what I'd really like to see is a more clean separation of >stable/unstable blocks, possibly with a clear directory hierarchy >(src/blocks/stable, src/blocks/unstable

Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit:cocoon-2.1/src/blocks/javaflow

Antonio Gallardo wrote: Stephan Michels dijo: Okay here another vote(and I wait more than 24h) Move java into scratchpad? [X] Move it into scratchpad [ ] Leave it where it is [ ] Rename it to ___ There is not JavascriptFlow Block. Antonio, While I share your feeling for simmetry and th

[cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox WoodyScratchpad Mon Mar 29 21:00:04 2004)

Since this starts looking like a consensus-reaching discussion I'm pulling it to the dev list others that want to join in, be sure to read up: Page: http://wiki.cocoondev.org/Wiki.jsp?page=WoodyScratchpad , version: 12 on Sun Mar 29 19:17:58 2004 by 65.116.199.19 + (tim: +1 to this alternativ

Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow

> > [ ] Move it into scratchpad > [X] Leave it where it is > [ ] Rename it to ___ Since this block is marked unstable, I dont see the need to move it anywhere else. cheers, Michael

Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: coco on-2.1/src/blocks/javaflow

Ralph Goers wrote: Second, at first I liked the idea of disabling unstable blocks by default, but after looking at blocks.properties I get the feeling that all that would do is make it a pain to get the sample site working, unless the build was changed to use a samples.blocks.properties to build t

Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow

Stephan Michels wrote: Okay here another vote(and I wait more than 24h) Move java into scratchpad? [ ] Move it into scratchpad [X] Leave it where it is [ ] Rename it to ___ IMO, this is a very much expected feature that a lot of people are waiting for. It needs to be marked as experim

Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow

On 30.03.2004 09:37, Stephan Michels wrote: Move java into scratchpad? [ ] Move it into scratchpad [ ] Leave it where it is [X] Rename it to "jflow" Joerg

RE: [VOTE] Move javaflow into scratchpad was RE: cvs commit: coco on-2.1/src/blocks/javaflow

First, I love the idea of Java Flow. However, I'd also like to see JavaScript Flow in a block so I can disable it if I want. Second, at first I liked the idea of disabling unstable blocks by default, but after looking at blocks.properties I get the feeling that all that would do is make it a pai

Re: Subversion support on eclipse

Antonio Gallardo wrote: Gianugo Rabellino dijo: Marc Portier wrote: (though what I'd really like to see is a more clean separation of stable/unstable blocks, possibly with a clear directory hierarchy (src/blocks/stable, src/blocks/unstable), a default commented out -1 on dir structure, cvs ha

Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit:cocoon-2.1/src/blocks/javaflow

Stephan Michels dijo: > Okay here another vote(and I wait more than 24h) > > Move java into scratchpad? > > [X] Move it into scratchpad > [ ] Leave it where it is > [ ] Rename it to ___ There is not JavascriptFlow Block. > My opinion is to leave it where it is, because I heard too much the >

Re: java continuations

Le 30 mars 04, à 10:45, Sylvain Wallez a écrit : ..."JS compiler" yes, but "our own" certainly not!! Rhino can produce regular class files from JS source code, and I was wondering it it would be possible to instrument these Rhino-generated classes with the continuation classloader... Ok, got it

Re: java continuations

You have different pros and cons about both implementations. Some users do not want to use javascrpt because of it's interpreted nature and some political issues (you cannot make your work closed source if you want to sell it). Java needs to be compiled, the container restarted for each change, >

Re: java continuations

Bertrand Delacretaz wrote: Le 29 mars 04, à 19:05, Sylvain Wallez a écrit : ...Ah, and would it be possible to use the class enhancer to enable continuations in a compiled (as in ".class") JS script? This may help us solving the current Rhino issues... This sounds interesting but I don't g

Re: Unstable stuff

Gianugo Rabellino wrote: Torsten Curdt wrote: Well, actually my point is about user awareness. Today you just download Cocoon, read the docs, type ./build.sh and see some fast-scrolling messages muttering about unstable stuff, and that's it. I'm thinking of something more specific that forces

Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow

Bertrand Delacretaz wrote: Le 30 mars 04, à 10:20, Marc Portier a écrit : ...just an idea popping up: why not reverse the default exclude.block.XXX setting for the unstable ones? then people will need to enable those and thus be more explicitely confronted?... I like the idea, and it's easy

Subversion support on eclipse (was: Re: [VOTE] Move javaflow...)

Gianugo Rabellino dijo: > Marc Portier wrote: > >>> (though what I'd really like to see is a more clean separation of >>> stable/unstable blocks, possibly with a clear directory hierarchy >>> (src/blocks/stable, src/blocks/unstable), a default commented out >> >> >> -1 on dir structure, cvs hastle

Re: java continuations

On Mon, Mar 29, 2004 at 05:11:45PM +0200, Torsten Curdt wrote: > >I really value all the work and effort that you all put into this, > >but I would say: > > > >[X] nah... put it somewhere else > > Uff... a bit discouraging I have to admit. > Actually I hoped noone would pick that option. > > >We

Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow

Le 30 mars 04, à 10:20, Marc Portier a écrit : ...just an idea popping up: why not reverse the default exclude.block.XXX setting for the unstable ones? then people will need to enable those and thus be more explicitely confronted?... I like the idea, and it's easy to do as blocks.properties are

  1   2   >