cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <reinh...@apache.org>
Subject Re: [Kernel22] How to develop a component?
Date Wed, 07 Apr 2004 06:21:17 GMT
Stefano Mazzocchi wrote:

> Sylvain Wallez wrote:
>
>> Nicola Ken Barozzi wrote:
>>
>>> Carsten Ziegeler wrote:
>>> ...
>>>
>>>>> I strongly suggest that we start with org.apache.cocoon.* to avoid 
>>>>> these problems down the road (including, yes, gump problems)
>>>>
>>>>
>>>>
>>>>
>>>> Yes, I understand of course all these problems, but I'm really afraid
>>>> of changing all the components now from Avalon interfaces to Cocoon
>>>> interfaces which are more or less the same but just use a different
>>>> package. In that case these components run in Cocoon but not in any
>>>> other container anymore that provides Avalon compatibility. And
>>>> that's imho bad. Not every project uses Cocoon, so it's absolutely 
>>>> preferable to have components that I can use in several projects.
>>>>
>>>> Ok, I think if we decide to use our own versions of the interfaces it
>>>> will still be possible to do some hacky things and still provide
>>>> compatilibity with the Avalon versions.
>>>>
>>>> So what do others think?
>>>
>>>
>>>
>>>
>>> Cocoon components will never work putside of Cocoon.
>>> Non-cocoon components should not use the Cocoon interfaces.
>>>
>>> I don't see the problem, as long as we don't mix all like we did 
>>> with Avalon.
>>
>>
>>
>>
>> IMO, the answer isn't so simple. A lot of people chose to use Avalon 
>> interfaces to implement component-based systems, especially for 
>> components related to business logic. These components can run inside 
>> Cocoon, but not only. And this choice was made possible because the 
>> COP-related interfaces are defined by outside of Cocoon, i.e. they 
>> aren't tied to the web tier in a more global architecture.
>>
>> Now what if COP-related interfaces are defined within Cocoon? People 
>> are left alone to write their business-related components. This is a 
>> giant step back.
>>
>>
>> Also, I think the block kernel and ECM serve different complementary 
>> purposes. The kernel is useful to implement coarse-grained entities 
>> (blocks) that can be hotdeployed and hotswapped. ECM is useful to 
>> implement fine-grained entities (components) that need to be 
>> configured, eventually pooled, etc. But ECM-managed components aren't 
>> individually hotswappable (they don't need to).
>>
>> So we can consider that there actually exists two levels of 
>> containement. Blocks are managed by the kernel, and components are 
>> managed by an ECM-type container, which, being part of a block is 
>> itself managed by the kernel.
>>
>> This approach has the benefit of being an evolutionary path of what 
>> we have today and still allows people to benefit from COP interfaces 
>> to implement their own components, be them integrated into Cocoon or 
>> not.
>>
>> WDYT?
>
>
> On paper, yes, but in real life it's not so simple.
>
> Avalon/ECM cannot define hotswappable components. This means that if 
> your block has ECM components they cannot be exposed to other blocks, 
> otherwise they would create "hard wires" between the two components 
> that will not allow the blocks to be hotswappable.
>
> So, like we already said before, it is *totally* possible to have a 
> block load avalon components thru an avalon sandbox (sort of a 
> avalon->cocoon adapter). This allows you to reuse your avalon stuff 
> "AS IS". But this also means that your block cannot expose those 
> components outside of that block.


Are there reasons that prevent me from writting a 'block wrapper' which 
can be exposed?

> This *is* already planned and allows you to keep your existing stuff, 
> but there is no way you can have the avalon interfaces cooperate with 
> the existing cocoon kernel functionality because of the intrinsic 
> nature of an hotswappale mechanism.
>

-- 
Reinhard


Mime
View raw message