I just wanted to raise a small flag for data types, as used by the Rules module.
Very briefly summarized, they work/are used like this:
- Every Rules plugin define which data type it requires, and also any new data types it provides.
- Data types can be nodes, users, unspecified entities, integers, text strings, and quite a few other things.
- It is also possible to specify that the data type is undecided – later configuration will determine what data type is.
- Every data type can also be represented as a list – meaning an array of none, one, or many data entries.
- Entities may be declared to have relations to other entities – for example, node references add relations from a node to another one by means of configuration, while the "site" data object has an always-present relation to the acting user.
As an example, the Rules event "after updating existing content" declares that it provides two node objects – the updated node, and an object representing the node as it was before it was saved. The action "remove an item from a list" declares that it requires one list (of any type) and one data object of (at the time) unknown type.
All of this looks pretty much like the context plugins in CTools, but with at least one important difference – there are no additional forms used for configuration in Rules. If you had an action "set node title", it would take a node data type and a text data type. Rules makes no assumptions on whether you want to inherit the values from other objects (setting title to "user:name") or just enter stuff manually – and the configurations forms are built to match this.
This data management is not really a part of Rules, but of Entity API (surprise), but the best place to see it in action is probably Rules. I am not suggesting that Entity API has a superior way of managing data plugins, but I am definately suggesting that it is worth looking at how it is crafted and used.
Two good starting places are:
Ok, that's it.
(/me ducks and prepares for comments)