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