Closed (duplicate)
Project:
Drupal core
Version:
8.0.x-dev
Component:
base system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
11 Oct 2010 at 16:00 UTC
Updated:
29 Jul 2014 at 19:05 UTC
I think exportables in d7 shot build upon Drupal's entity API, so let's discuss that. As ctools is currently the home of exportables I'm posting it in its queue.
Why?
Because I think with D7 with the start of generic CRUD API, the entity API. In d8 we hopefully have full CRUD support. We do not want to have a different API for exportables then. For D7 I've implemented a full CRUD controller more.
Current status
I've already implemented it for the entity CRUD API (help welcome!!), so optionally entities may be defined to be exportable. I'm using that already quite some time for Rules, Profile2 and some other WIP modules.
Basically modules providing an entity via the entity CRUD API get CRUD
for free. If they also set 'exportable' => TRUE in hook entity info, it
is exportable too and gets a name key.
E.g. I'm using that for profile2, where I create 2 entity types:
* The "profile" type, fieldable, not exportable.
* The "profile_type" type, not fieldable, exportable, the bundle of
profiles (analogous to node types)
Opinions on that?
Comments
Comment #1
fagoas I cannot edit that post, here is the correction of the "Why" part...
Why?
Because with D7 we have the start of a generic CRUD API, the entity API. In d8 we hopefully have full CRUD support. We do not want to have a different API for entities and exportables then. For D7 I've implemented a full entity CRUD controller in contrib -> see here
Comment #2
merlinofchaos commentedThe exportables code is not going to be rewritten in the D7 environment, so it can't build upon entities (and besides, I'm not yet sure that's right. That means turning a lot of things into entities and I have not yet evaluated whether or not entities are the right choice for many exportables).
I'm targeting D8 for a proper merging of exportables into D8 infrastructure. For D7, while I may try to find a way to tie more closely to entities, they're going to have to be separated just for the sake of expediency.
Comment #3
fagook, I see. Then I'll assign that to d8 for the sake of further discussing it.
related core issue #535122: Integrate CTools export.inc into core for declaring instances of objects
Comment #4
Crell commented(fago asked me to chime in here.)
As I've said before, I don't think that comingling content and config is a good thing. Entities I see as fundamentally content. They should be transferrable between sites, but that's a deployment question. Configuration, and its persistence, is a separate matter.
Entities have a different set of requirements from exportable/persistable configuration, and should be handled separately.
Comment #5
fagothanks!
I think it boils down to how we think about entities. To me, an entity is more a storage object, thus it must be at least loadable, but usually has full CRUD. That way I think of the entity API as our long needed unique API for doing CRUD (ala data API). Also I think, most people from outside the drupal world would have this association with the term "entity", as it's used similarly when modelling DB schemes (ER diagrams).
That way, I think configuration objects should make use of the same API for CRUD, so developers can use it the same way. We have already entities that are not fieldable in core, e.g. the vocabulary and files. Vocabularies are configuration and should be exportable, just as stuff like node types or filter formats.
I think it would be very valuable to have a single CRUD API everything is built upon, as that way it's easy to re-use the tools we build upon those API in other situations too.
Deploying configuration changes is an important issue to solve, but I agree that's a separate matter and should not influence this. Transferring content (-> usually the fieldable entities) between sites is different, e.g. as you wanna do it between production sites too.
@comingling content & config:
Well, with exportable entities it's still different as not every entity is exportable; it's just built upon the same API. But apart from that I think it's not possible to draw a hard line between content & configuration. E.g. are Rules configuration or content? I'd probably say configuration, but what if one writes a module allowing users the creation of some simple rules? These rules are more content then. So whether something is content or configuration, sometimes just depends on how people use things. An often recurring problem are terms here - which are often used as content, but also often pre-configured as configuration.
I don't know a solution to that problem, maybe exportable entities could help here or not. But anyway, separating configuration and content even more won't help us on that front.
Comment #6
mlncn commentedI am certainly a believer in separating configuration from content; this is the way we (and many other Drupalistas) deploy changes to live sites. However, Drupal has this huge site building (potential) grey area, as fago highlighted. A key power and attraction of Drupal is precisely how much you can do through configuring rather than code.
To reach its full potential as THE site builder's platform, Drupal needs a way to track who made configuration changes and the ability to roll them back when these changes are made via configuring the user interface. Even when every piece of configuration is exportable we cannot ensure that everybody follows a workflow of configuring in isolation, exporting their changes, committing to a shared repository... even if the live site is locked down, a Drupalish workflow naturally tends toward collaboration in configuration as with everything else.
Proposed principle: On a site with multiple site-building administrators, "Configuration is Content", in the sense that we want the basic content goodies of revisions identified with a timestamp and a user ID.
Entities have revisions. Fago's given them exportables. (Note: The revisions should not be exportable. That way lies madness.) If we can flag what is content (meaning from a workflow perspective controlled on the live site) and what is configuration (meaning for the ordinary workflow that the code will expect to override the on-site configuration, and ideally the UI could be easily locked on live) on a per-bundle basis i think we get the best of all possible worlds :-)
Note that this content/config flag for bundles (think vocabularies, rule sets, etc) is different from the exportable capability, which should continue to be an entity-level ability. (Also i don't think all exportables have to become entities, but other exportables (such as Views) should understand the same content/config concept and flagging, and in general we'll want as much of the exportable API and UI to be shared.)
Comment #7
xjmNow we have config entities. :)
Comment #8
xjmBetter status.