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 project

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 Gi

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 u

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 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 place prior

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

Sylvain Wallez wrote: Ricardo Rocha wrote: So 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

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 st

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 free

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 does not support). - The cocoon.releaseComponent(component) method should be supp

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 more

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 does not support). - The cocoon.releaseComponent

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 we

Re: [vote] FOM design methodology

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