<lots-of-cool-stuff-snipped/>
...This means that, in order to achieve, back compatibility, when a block is deployed on cocoon, the sitemap interpreter asks the block manager whether or not there is some mounted block that matches the incoming request, if so, that block is invoqued, otherwise, it falls back on the main sitemap.
This implies that it's entirely possible that a block "obscures" pipelines located in the mail cocoon sitemap (or subsitemaps mounted the direct way in there), but it is suggested that the sitemap interpreter doesn't fallback to the main sitemap if the block sitemap is invoqued, but no matching pipeline is located. This is to avoid potentially dangerous (security-wise) holes in the block URL-space covering that could lead to hard to forecast issues...
Sounds good but maybe making the "block matching" explicit in the sitemap would be clearer, something like <map:match-blocks/> that can be placed at the same level than map:match to control when the "block matching" happens.
Use cases:
1) temporarily disable a block by matching its URL before map:match-blocks (for maintenance and testing purposes)
2) easily debug possible conflicts between blocks and non-blocks matchers, by moving match-blocks around.
3) completely disable blocks by not having map:match-blocks in the sitemap
Thoughts?
-Bertrand
