cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] The block protocol
Date Tue, 05 Apr 2005 16:53:47 GMT
Reinhard Poetz wrote:
> Vadim Gritsenko wrote:
> 
>> Reinhard Poetz wrote:
>>
>>> Ralph Goers wrote:
>>>
>>>> Daniel Fagerstrom wrote:
>>>>
>>>> Portal block
>>>> ------------
>>>> - requires "MyProfile" that implements "profile"
>>
>>
>>
>> Correction:
>>
>>   - Requires implementation of "profile" interface.
>>     "profile" is implemented by "MyProfile1",
>>     "MyProfile2", ..., "MyProfileN".
>>
>>
>>>> <profiles>
>>>>  <copletbasedata-load
>>>>   uri="blocks:profile:/load-global-profile?profile=copletbasedata"/>
>>>>  <copletdata-global-load
>>>>   uri="blocks:profile:/load-global-profile?profile=copletdata"/>
>>>>   ..
>>>> </profiles>
>>>>
>>>> The problem with this example is that is not how the portal works, 
>>>> nor would I ever want the portal to require that a block with a 
>>>> specific name be present as this prohibits two portal 
>>>> implementations from being present in the same webapp. 
>>>
>>>
>>>
>>>
>>> That's not true. You can deploy as many portal applications as real 
>>> blocks as you want.
>>
>>
>>
>> Yes
>>
>>
>>> And, if you don't like dependencies (references, extensions) just 
>>> don't use them.
>>
>>
>>
>> And No. If portal block requires implementation of profile block, 
>> during its deployment time you will pick up an implementation you like 
>> for each instance of portal block.
> 
> 
> ... stand corrected
> 
> and you have always the chance that you can do it the same way as it is 
> done now: simply copy everything that you need into your own application.
> 
> If people really want this, the portal block could have a "base" version 
> that only contains the components (e.g. the PortalGenerator) and a 
> "default" version that extends the base version and requires a "profile" 
> block.
> 
> Then people who like blocks and that functionality is spreat over 
> several blocks extend the "default" version and people who don't want to 
> change the way how they work with Cocoon, use the "base" block that only 
> contains components.

There are two concerns here, not totally unrelated, but enough so:

  1) what features should the block system have

  2) what is the best way to use those features in order to achieve what 
I need

We have a pretty good understanding of 1) (and meets *all* the 
requirements that I came across so far!) but have no idea on best 
practices for 2)

I would strongly suggest we avoid discussing #2 before we even implement 
#1 to test it out.

Obviously, the two cannot be completely isolated, because #1 influences 
#2 and problems in #2 should influence back #1, so the cycle will be 
iterative, but for now, let's focus on what we understand of #1 and move 
on until we have a better understanding of the problems on #2.

-- 
Stefano.


Mime
View raw message