Apr 5, 2011 at 5:43 PM
Edited Apr 5, 2011 at 5:44 PM
Something that I'm not sure if you're aware of is that a rule can hide a layer as well as show it. (By setting ruleContext.Result = false)
So you set up your various default layers with their "show" rules. Then as the final rule(s) on each have a set of "hide" rules that will respond to specific affiliates or affiliate conditions / options.
Finally have a set of affiliate layers with "show" rules according to how it should be set up for different affiliates (these would probably in all cases have the same set of "show" rules but the
inverses to the "hide" rules of the default layers). On these layers you include your replacement widgets.
Hope that makes sense ;)
This sounds to me a bit more straightforward than layer groups and overriding situations, each layer has a straight-up known and easily debuggable set of show/hide conditions.
The problem I can imagine creeping in with groups and overrides is that, particularly once you had loads of affiliates and therefore tons of layers and rules, you'd enter situations where you're thinking "why won't
that layer display?" And it'll be really hard to untangle the set of conditions contributing to any given display state.
Maybe what I've described won't fit all the required permutations of your system. But I'd think you'd have trouble defining
any system that can easily handle so many varying conditions and edge cases. But if what you've got works, stick with it :)
BTW, I haven't been using Orchard all that long either, I've just had plenty of time to get stuck in and it has a lot of similar concepts to a framework I was developing myself, so I've taken to it quite easily!
Edit: Just saw betrand's reply, and yes if layers aren't giving you what you need then just write your own system to push shapes into zones in whatever manner suits you.