Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <406A9F9A.4070603@anyware-tech.com>
Date: Wed, 31 Mar 2004 12:38:18 +0200
From: =?ISO-8859-1?Q?C=E9dric_Damioli?= <cedric.damioli@anyware-tech.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.3) Gecko/20030312
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: CocoonTask
References: <406A9162.3050007@anyware-tech.com> <406A9563.4070009@upaya.co.uk>
In-Reply-To: <406A9563.4070009@upaya.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Upayavira wrote:

> C�dric Damioli wrote:
>
>> Hi,
>>
>> I'm using CocoonTask, wich allow CocoonBean to be embedded in a Ant 
>> build script. 
>
>
> Great. I'm glad to hear you're using it. 

I'm actually running Cocoon in a servlet, which periodically executes an 
Ant build script ending with the CocoonTask :-) Seems complex, but is 
really effective !!!
And your work on the CLI is great and very appreciated ;-)

>
>
>> I'm wondering if there's any reasons why there's no access (via 
>> protected method or fields or whatever) to the CocoonBean.
>
>
> Basically, the CocoonBean is invoked via reflection, using a different 
> classloader. Now, I'm no reflection expert, and calling each getter 
> and setter one at a time using reflection seemed unreasonably complex. 
> So, I chose to create a Delegate class, invoke that with reflection, 
> and have that do the real work. 

I'm ok with the concept of "single entry point", but what I wanted is 
the possibility to act on the CocoonBean before processing the different 
uris.
Imagine you have a Java method returning a Collection of uris to be 
processed, you may want to directly fill the CocoonBean with this 
Collection, instead of dynamically re-creating the CocoonBean configuration.

>> I wanted to use it directly to add BeanListeners, eventually add 
>> targets, and so on...
>
>
> What sort of listeners would you like to add? If you want to specify a 
> different listener, I would suggest coming up with a generic way to 
> specify listeners and add that to the BeanConfigurator, so that all 
> users of the CLI and Ant task get to benefit. 

I wanted to add org.apache.cocoon.bean.BeanListener implementations to 
my instance of CocoonBean.
The problem with adding this at BeanConfigurator level is that we can't 
interact with the Ant Project (or its Properties), for example, or 
whatever is not directly tied to the Bean.

>> IMHO, the best way to "open" the CocoonTask is to allow subclasses to 
>> change the delegate class 
>> ("org.apache.cocoon.bean.helpers.AntDelegate" at the moment) and to 
>> give this delegate access to the calling Ant project.
>
>
> So you supply a piece of java that configures the bean before running? 
> Hmmm, I would much rather extend the xconf format to be able to add 
> everything you want. The CocoonTask really should not assume any Java 
> knowledge in its users. 

Of course, but I think that the xconf format is already very complete 
for users who do not want to write any Java code : all the setters of 
the Bean have their counterparts in the xconf format (except the 
addBuildListener). The next step would be to add a syntax to add Java 
entry points (such as  : <listener class="..."/> or <configurator 
class="..."/>) but users of such a syntax would have to write Java code 
anyway.

What I proposed is to have the possibility to extend the CocoonTask (or 
the AntDelegate, or both) to provide access to users (such as me :-) ) 
who want to have more control over the Bean.

>
>
> Regards, Upayavira
>
>
C�dric