Allow links to reuse condition sets for visibility, rather than providing their own

Yeah, also have thought of this, although currently you already can reuse components, because rules lets you embed components into other components. But is not very user friendly...

Hi,

I second Itangalo's suggestion (and his "thanks for a cool module"), and I even would like to push it further, and suggest that the actions triggerred should also reuse an existing rule set (or a rule, or an action set). Since you cannot (simply) avoid the visibility condition and the action ruleset to show among the Rules components, this approach would be simpler to understand from the user's viewpoint. Rule links would then simply be... links to rules.

Note also that this approach would simply cancel the "bug" you mention on the module's description page ("you get the default Rules bread crumbs and you'll be stuck there and will manually have to go back in your Browser").

Regards.

I gave the whole thing a thought, but I think it would complicate the code and the work flow unnecessarily. If for example two links share the same visibility conditions, rules link would have to track which components are shared and notify the user on the link edit pages, when the conditions have changed, otherwise the use may be confused why his links won't show up (this may especially be a problem if more than one person is configuring the links).

I read #3 yesterday afternoon and, although I the hadn't time for posting an answer, it was (once again) very close to Itangalo's one: not convinced, but I'm not the one at the keyboard.

Let me just expose my argument. If rule links only refer to rule components, these components will have a 1st-class status. The users will consciously use them to implement a given, precise logic. Therefore, if several links use the same rule component (as their visibility conditions, for example), they will do so because they precisely want to use the component's logic. If the rule component is modified, it's because the implementation of the logic evolves. However the rule links that refer to the component still refer to the logic, and should be ok with the evolution of its implementation.

Basically, the argument is that with a "rule links refer to rule components" approach, the assumption is that the users know what they are doing: they write rule components that implement stuff, and use these components in rule links (could be elsewhere as well, such as in views filters) to achieve further goals. This does not suppress the interest of providing users with a list of all rule links that refer to a given rule components, or stuff like that. But in this approach, the coupling is light and each module focuses on its core task.

It may be a matter of taste, but I personnally do not like much thoses modules or themes that claim "just click here and there and everything works magically". I prefer when concepts are explained to me, so that I can use the things with confidence. This does not mean that the "rules components are embedded in rule links" approach is totally wrong: it can be helpful to users who do not know rules and do not want to dive into that subject. Still, my take is that the latter approach could probably be built on top of the former, hence providing a complete range of features.

Once again, please do not take all these thoughts for more than what they are: comments by someone who has much interest in your work, but no rights (nor will) in anyway to dictate what you should do.

Cheers.

Couldn't we replace the visibility conditions feature entirely with Rules Forms Support? I understand why it makes sense to have this functionality for this project, but AFAIR, that module would allow for exactly what is described in this issue as well as other general needs.