hello

Should Butler have Contexts API, Access Rules/Conditions API and Relationships API?

This idea comes from the following rationale:

* CTools module provides Contexts and Access Rules. Additionally, Arguments and Relationships might be provided by CTools.

* Panels is a great module that uses CTools extensively, by exploiting Contexts and Access Rules (Rulesets), and also Arguments and Relationships, the Page Manager and AJAX framework (which got implemented on D7 core).

* Views (3.x) currently depends to CTools. #646284: Status of Views 3 Roadmap:
I haven't examined the code, but it seems plausible that Views will use/uses Contexts and Access Rules from CTools, as well as the Page Manager (read somewhere), and maybe got/will get the Arguments and Relationships from it, or keep the code for that from 2.x.

* Context module, which requires CTools, provides a way to arrange blocks, by using Contexts/Conditions. I'm not sure how this relates to CTools or if Context module uses just the AJAX framework and little more. The module tries to replace the Blocks system (or complement it).

btw, regarding that, Block 2.0 and Boxes have similar approaches, but have nothing to do with Contexts, Access Rules, etc.

* Panels Everywhere requires CTools for it's Contexts and Access Rules (and Relationships?), and also Panels and anything it requires or uses from CTools (like Page Manager and AJAX framework). This is a solid solution, yet complex, to replace entirely the blocks system, like Context module does.

* Rules uses Conditions to determine whether or not to execute Actions or Rule Sets (think core Actions module), when a Event (think core Trigger module) is fired. Rules also deals partially with Arguments. This module was made to replace Actions and Triggers from Core, and other similar modules - and effectively it does - Full Events/Triggers and Actions is already implemented in Rules. It also integrates with Token, a module that was moved to D7 core.

Also FYI, the Trigger module from core is being removed in D8 core, but is still retaining the Actions module. #764558: Remove Trigger module from core

Noting that in Drupal contrib:

* Arguments is a way to pass simple arguments to a page or module (...);
* Contexts is a way to pass contextual information to modules and pages (CTools vs Context);
* Relationships combines/relates pieces of content, like Node Author with Node ID (Drupal itself does some of these relations automatically, perhaps that is not optimal) (Core vs CTools);
* Events is a scheduled, machine or user action, that can be used to trigger something (Core Triggers vs Rules Events);
* Access Rules sets a way to define on which condition something will happen (CTools Rulesets vs Rules Conditions);
* Actions is a given command/action, to be called given certain events and/or conditions (Core Actions vs Rules Actions/Rule Sets);

Some conclusions:

a) it would make sense to have Butler deal with anything that is SESSION, Arguments, Contexts and Relationships;
b) Access Rules/Conditions:
....b.1) move to Butler (makes sense IF rules is not in core);
....b.2) move to Rules (implemented partially? fully?);
c) Events/Triggers:
...c.1) move to Butler (being removed from D8 core);
...c.2) move to Rules (fully implemented already);
d) eventually deprecate and remove Actions module from core (D9?) so that Actions is dealt by Rules module only:

I'm thinking A + B1 + C2 + D, because it's not very likely at the moment that Rules will get into D8 or D9 core, and some of Access Rules code needs to live in core, so it might live instead in a unified way in Butler if Rules does not get in core. #1211396: [META] Rules: Drupal 8 port

By doing this, we could effectively remove these pieces of code from miscellaneous places in Core (moved to Butler API in core), Rules, CTools and Context modules, and any other modules that use custom code, like perhaps Domain, OG, etc.

Then Rules, Context, Panels (thus Minipanels and Panels Everywhere), Views, etc could plug into Butler to get the relevant APIs and do their thing.

Comments

Issue summary:View changes

Triggers/Events

Issue summary:View changes

cleanup

Issue summary:View changes

some more cleanup

Issue summary:View changes

yet more changes

I think I need to offer a bit more background to answer that...

"Butler" is, really, the legacy name of the initiative. We should probably stop using it. :-( The over-arching WSCCI initiative includes context (the "butler" system) as well as a unified plugin system. This project (/project/butler) is specifically a workspace for building the context system only.

Currently, ctools provides its own form of context, as well as a plugin mechanism. One simple type of ctools plugin is an access plugin, which is *not* part of context but is able to *consume* context in order to decide whether to return true or false. I believe that is a good model, and would argue that one of the first plugin types we want to implement in core once we have the plugin system in place is a common context-aware access system that all of Drupal can easily leverage. The access plugin itself, though, is not part of context proper. (If my understanding of ctools is incorrect I'm sure EclipseGC will correct me momentarily. :-) )

At the time being, Rules/Actions/Triggers/Events are out of scope for WSCCI. We've got enough to do as is, let's not try to bite off even more if we can avoid it. :-) That said, if we do have a good clean unified plugin system then I would absolutely support building an enhanced core-actions system using plugins and context. In that model, an action would be a plugin type with an execute() method, most likely. I see no reason that couldn't be context sensitive as well.

For context relations... that's something we probably want to have at least some idea of how to handle in the core context system even if much of the details are left to implementers case-by-case. We haven't worked out yet how that would work. Thoughts on this front are welcome.

The Phase 4 work is, when you get right down to it, "Panels Everywhere in Core" (at leas at the 50,000 foot level), so that is a model we are trying to draw from for inspiration.

nice clarification :)

i'll let Rules devs know of this

i've been dreaming for a while for the day that Panels and Panels Everywhere gets in core, with Views.
and now Panelizer too...

That said, if we do have a good clean unified plugin system then I would absolutely support building an enhanced core-actions system using plugins and context. In that model, an action would be a plugin type with an execute() method, most likely. I see no reason that couldn't be context sensitive as well.

I think Rules can benefit much from plugins and the context system, and needs probably be revised to work on top of that/with that.

At the time being, Rules/Actions/Triggers/Events are out of scope for WSCCI. We've got enough to do as is, let's not try to bite off even more if we can avoid it. :-)

Agreed - let's get the basics done first without loosing scope.

Status:Active» Fixed

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Issue summary:View changes

okay i need to go sleep