cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Damioli <cedric.dami...@anyware-tech.com>
Subject Re: CocoonTask
Date Fri, 02 Apr 2004 12:13:23 GMT
Upayavira,

Any thoughts about this ?
Or do you prefer that I come up with a concrete proposal ? :-)

Cédric


Cédric Damioli wrote:

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



Mime
View raw message