Re: [vote] Ricardo as Apache representative in JSR-152

John Morrison wrote: I'd be quite happy for him to do the job - but I don't think that I've heard him say he would like to yet! :-)) I think I've already said so but here it goes: I'd like to participate on behalf of the Apache Cocoon community and, in particular, as a carrier of our

Re: [donation]XML:DB pseudo protocol

I'd like to propose Gianugo Rabellino as a new commiter to the cocoon community. He has produced alot of patches in the past and is very engaged in the dbxml parts of cocoon which I think would be best if he can do it directly in CVS rather than badging us with patches. Enthusiastic +1 for

Re: org.apache.cocoon.components.language.programming.java package

Paul Hammant wrote: (interloping from the AvalonDB server project) We'd like to be able to use a technique where we compile SQL SELECT statements into Java class actions. OK, so this is a non-rendering class, but it has similar aspects to JSP and XSP pages in that it is cached and used

President Of India Advocates OSS

Found this on Slashdot: http://timesofindia.indiatimes.com/cms.dll/html/uncomp/articleshow?msid=47799819

Re: extending XSP base call

Konstantin Piroumian wrote: From: Geoff Howard [EMAIL PROTECTED] Thorsten Mauch wrote: I like to add some common methods. As a pure jave programmer I hate logicsheets ;( So is it possible to extend the the class XSPGenerator and tell Cocoon to use this class as a base class for the XSP ? No.

Re: C2.0.4: Strange XSLT behaviour in logicsheet when matching text() nodes (resent)

Sylvain Wallez wrote: IIRC (but don't ask me why), the XSP engine wraps every text node from the XSP file into xsp:text elements. In the original implementation text nodes were preprocessed and escaped as string constants in accordance to the rules of the target programming language. This took

Re: C2.0.4: Strange XSLT behaviour in logicsheet when matching text() nodes (resent)

Sylvain Wallez wrote: Ricardo Rocha wrote: snip/ So xsp:text is probably a venerable fossil today. That said, if it ain't broken... Ah yes, I remember that, now. Gosh, the ancient times of Cocoon 1.x... Thanks for refreshing our memory, Ricardo. In fact, I was refering to the first Cocoon *2

FOM and stateful components

As originally proposed by Stefano, the FOM exposes a getComponent(id) method but not a corresponding releaseComponent(component), as Sylvain was quick to point out. I agree with Sylvain that releaseComponent() is indeed needed for stateful, pooled components. Btw, I'm sure when Stefano mentioned

Re: [vote] FOM design methodology

Stefano Mazzocchi wrote: 1) big to small - give users all possible freedom and restrict that freedom once we understand potentially problematic usages. 2) small to big - give users the least possible freedom based on some required functionality and grow as the users express their needs. +1 for

Re: [vote] FOM design methodology

Joerg Heinicke wrote: 2) small to big +1 from me Ricardo Rocha wrote: Stefano Mazzocchi wrote: 1) big to small - give users all possible freedom and restrict that freedom once we understand potentially problematic usages. 2) small to big - give users the least possible freedom based

Re: looking at linotype

Jeremy Quinn wrote: Since the login() method calls 'cocoon.createSession()', should the 'logout()' method not invalidate the Session? Is there a method available in the FOM to do that? I could not work out what I guess cocoon.session.invalidate() should do the trick? Ricardo

Re: [vote] Reinhard Potz as a Cocoon committer

+1, welcome

More on FOM

Hi friends, The following items reflect the discussions Stefano and I have had around the FOM: - The load(uri) global function should be supported. This is clearly needed for nested source file inclusion (which map:script does not support). - The cocoon.releaseComponent(component) method

Re: More on FOM

Reinhard Pötz wrote: - There should be unrestricted access to all components via cocoon.getComponent(id). I'll implement getComponent( id ) and releaseComponent( component) ASAP because the current flow implementation exposes the component manager and this leads to a serious bug! If you have

Re: More on FOM

Sylvain Wallez wrote: Ricardo Rocha wrote: The following items reflect the discussions Stefano and I have had around the FOM: - The load(uri) global function should be supported. This is clearly needed for nested source file inclusion (which map:script does not support

Continuation patterns (too long!)

Hi friends, Is this a rant? A random thought? A pontification? Well, let's say it's just a personal story (and a concern) I want to share with my fellow Cocooners... Someone said continuations can be grasped in five minutes, but it may take a lifetime to master them :-) When first introduced to

Re: [vote] FOM design methodology

Giacomo Pati wrote: I'm late, I know ;-) But welcome anyway!