More user-friendly Layer Rules management?

Topics: Administration
Oct 26, 2012 at 1:54 AM

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 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?

Oct 26, 2012 at 2:01 AM
Edited Oct 26, 2012 at 2:01 AM

Well, query builders, and in general UI that attempt to graphically represent a procedural process, tend to fail miserably to simplify things and only add confusion and constraints. I do agree with your suggestion to have descriptors for rules. We have them for tokens for example and it works great.

One thing we could do to make this more approachable would be to have a simple or-based list of rules, which would cover the most common scenarios and would be easy to persist as a script, with a switch to full script for more advanced users. The usage of a hierarchical view to represent more complex conditions is creative, I'll concede, but if you understand that, you would probably also understand a text expression just as well, if not better.

Oct 26, 2012 at 2:18 AM

Orchard could be the first to succeed in making a perfect graphical representation of this! Ahh, just kidding... :-)

I see your point, and of course you are right - maybe I was just a bit inspired of how easy the Orchard devs have made the process of making queries/projections (as an example). And I totally buy your argument about a hierarchical representation vs a text expression.

Using descriptors, like they are used in tokens, is a really good example of a direction for a practical 'solution'. I haven't really been looking so much in to how Tokens works behind the scenes (yet!), but it definitly could be a more simple and elegant way of doing it?

Oct 26, 2012 at 2:29 AM

It could even provide some rudimentary code completion based on those descriptions.

Oct 26, 2012 at 10:38 AM
bertrandleroy wrote:

... One thing we could do to make this more approachable would be to have a simple or-based list of rules, which would cover the most common scenarios and would be easy to persist as a script, with a switch to full script for more advanced users. ...

Maybe a simple visual 'boxing' of grouped rules (parentheses) could be a way to achieve a more user-friendly look and highlighting rules that are 'valid' green. But I really like the idea of a two-sided editor, with a switch for full code.

Anyway, first step would be adding descriptors or similiar for the rules.

What would be the best way to propose this idea as a future extension for Orchard? I mean, it is still very conceptual. Should I just create a work item?

Oct 26, 2012 at 8:34 PM

Yes, a work item is a start, and you can attend the Tuesday meetings and advocate for it, build a prototype, etc.