> Let's make an example: suppose you have three concern realms A,B,C each > with a different 'component' view of the problem and some overlap. > > A [ | | | ] > B [ | | | ] > C [ | | | | ] > > the idea is to have a higher granularity of componentization > > [ | | | | | | | | ] > > and then somewhat glue togheter the components in the same realm > > A [ * * * | | * * | ] > B [ | * | * * * | * ] > C [ * | * | * | | * ] > > An example of such a 'glue' is content aggregation: things that were > componentized at the 'logic' level are glued back together at 'content' > level. > > The drawback is that we have a higher number of 'marks' in the picture > (both '*' and '|') and each one of them is a contract, so eventually > requiring changes and possibly impacting more than one concern island. >
I agree that the increased number of contracts makes this an arduous situation. (I'm also responding having read your response to Berin, so this is somewhat imformed by that thread...) It seems to me that Cocoon proposed very clearly the contracts: Content - Design Design - Development Management -Content Management - Design Management - Development (this is from memory, so I may have substituted a fictional contract for a real one.) >From a philosophical point of view, I'd like to keep any new contracts within the production roles outlined in those contracts. Prehaps add a ContentManagement - DesignManagement contract, but if at all possible avoid adding a SessionControllDevelopment - FormContent contract, if you see what I mean. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
