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.
