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".
>
>
>>>
>>> >> uri="blocks:profile:/load-global-profile?profile=copletbasedata"/>
>>> >> uri="blocks:profile:/load-global-profile?profile=copletdata"/>
>>> ..
>>>
>>>
>>> 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.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------