The layer rules are one of the few things in the Orchard back-end, that (in my opinion) are a bit more "technical". Users have to know some basic scripting, if they want to make a new layer with specific rules. Pre Orchard 1.5, the navigation
was a bit techincal, and prior to that, routes were...so I thought it might be time to look a bit into the way layer rules works?
The module, "Page Layer Hinting" is of course a way to make it a bit easier for novice users, but the whole concept is still a "technical" thing.
Personally, I think one of the main 'issues' are, that rules are not listed nor documented when they are added in a module. There is no list of possible rules, they are just applied on the fly (sort of).
Conceptually, I was thinking about something like rules builded as fields instead of being injected as IRuleProviders. So all rules have a name and some hard-coded, custom options (like a content-picker/alias-looking field for content
url's, a text-field for custom urls, a drop-down or check-box list for roles etc.) and of course a logic operator, returning true/false based on the rules "fields".
So extending/changing the concept in the widget module, namely the RuleContext, to be some field interface (or similiar) for easily creating new layer rules (both back-end and in code).
Like the new navigation interface (I love it btw.), the layer rules could 'simply' be added from a list, and seperated by dropdowns with options like "AND/OR" +"NOT" and then visualized in a view.
I'm aware, that this suggestion is not a quick fix module done over a night and this is not something to consider before a release 2.0+. The concept I suggested should most likely also be done in a few steps, maybe starting by
changing the RuleContext to fields.
My concerns on my own suggestions are, 1) that it's crucial to maintain a really high performance on executing the layer rules, 2) that writing new custom rules should not be limited in possible functionality and 3) writing the layer
rules should also not be limited in the logical possibilities.
I couldn't find any other discussions or suggestions on this specific topic, and I would really like to hear some other opinions on this matter? What do you think?
Could it be made more user-friendly in some easier way, based on what we already got?