Currently both Ctools and Entity API provide exportables APIs. Both feature:

  • Ability to designate a given data type as exportable. Ctools uses a flag in hook_schema(), while Entity API uses a flag in hook_entity_info().
  • UI for exportables.
  • Features module support.

In practice that module developers who want to add exportables and features support can choose between Entity API and Ctools. Since Ctools has been the preferred approach in Drupal 6, it continues to have the most modules using its API. WYSIWYG is currently introducing Entity API based exportables and features support, see #624018: Exportables and Features support for WYSIWYG 7.x.

As a result:

  • Features modules may require both Ctools and Entity API as dependencies.
  • Features module developers and users of features modules will distinct UIs for exportables handling (as well as any custom ones for modules not using the Ctools or Entity API UIs).

Two steps could help this situation.

1. Define and adopt a common means of designating data types (entities) as exportable. With this in place, a module could add exportables support
2. Ensure the Ctools and Entity API exportables UIs are as parallel as is practical.

The first is really the more important. It would mean that module developers wouldn't have to choose between Ctools and Entity API when adding exportables support. Features module developers could select one or the other as a dependency without requiring both.

How to harmonize? I'd lean towards hook_entity_info() as the common approach. Modules should be implementing hook_entity_info() in any case. Are there data types that should be exportable but should not be declared as entities?

Comments

fago’s picture

also see #681362: d7: Support exportable entities - well I'd say it mostly depends on whether you implement already an entity type or not - with that comes the difference of using hook_entity_info() or hook_schema().

I don't think the UI thing is really an issue now, but harmonizing on the API level sounds good though. As of know, the entity API works different as it syncs the entities defined in code to the database too - what makes it easy for developers to make use of the common CRUD hooks for exportables too.

merlinofchaos’s picture

Are there data types that should be exportable but should not be declared as entities?

Well, I look at it this way:

Which functionality is more necessary to the functioning of objects? The ability to be an entity, or the ability to be stored in the database?

By moving to hook_entity_api, we *force* entity-ness on objects that may not necessarily benefit from it. export.inc already forces objects into a given paradigm; forcing them into two different paradigms might be too much.

That said, I really do want to do something here, but I'm a little frustrated, because all of the export stuff in entity api was developed afterward with no consideration to the pre-existing patterns, and now export.inc is being told to catch up.

In D7, entities are not yet very mature. entity API is more mature, but I'm a little dubious about it. It adds a not insignificant amount of weight, while trying to force every peg, bolt, nut and banana into the same round hole. I still haven't had a chance to look too deeply at it, mind you, but I haven't been especially happy with entities in core itself, nor have I been especially happy with entity API's ideal of making every single thing in Drupal an entity whether you like it or not.

Finally: The actual syncing of an exportable to the database is not difficult. The part that I've struggled with is detecting when you need to do it. Currently there's no automated way of doing it, and I'm struggling to figure out how to do that properly without 1) having lots of stale data, or 2) causing some very expensive operations to run at inconvenient times.

fago’s picture

>That said, I really do want to do something here, but I'm a little frustrated, because all of the export stuff in entity api was developed afterward with no consideration to the pre-existing patterns, and now export.inc is being told to catch up.

I have no idea what makes you think pre-existing patterns were ignored, that's not the case.

>Finally: The actual syncing of an exportable to the database is not difficult. The part that I've struggled with is detecting when you need to do it. Currently there's no automated way of doing it, and I'm struggling to figure out how to do that properly without 1) having lots of stale data, or 2) causing some very expensive operations to run at inconvenient times.

Sry if #1 sounds like I want ctools to pick db-syncing up, I didn't mean to. I just wanted to point out the differences between the current implementations. I do not think the syncing is something we need to harmonize, honestly I currently can't even think of anything else.
As already said in #1 having the export-info in hook-entity-info / hook-schema comes with using entities or not. Still, streamlining the info-array keys if possible is surely a good idea. For that the entity API 's 'export' info-array is designed to hold ctools-compatible keys already (whereas itself it only picks the default hook up from there).

EclipseGc’s picture

I've been intending on digging into entity api and ctools as a potential single unit for a while here with very little success (i.e. I've not had the time). That being said I do see some potential ways forward, but I'd like to focus on nedjo's question for a moment just to put this to bed:

"Are there data types that should be exportable but should not be declared as entities?"

Yes, there are. The community is playing with various approaches here at the moment, but after some pretty in-depth work with core's entity system in page_manager I can say I've had no small measure of suffering from people's misuse of entities as some generic data holder that is NOT user facing. Core implements entities for nodes, users, terms, vocabularies, and I think that's it. All of these items (with the exception of vocabularies, which I'll come back to) are essentially data we will present to the users of our site. Using entities for configuration data is sort of a misnomer because the entity system appears to have largely been designed with user facing data in mind. Yes you can beat it into submission to do other things, but I submit to you that it's not a very good idea.

Vocabularies are where issues start to get fuzzy. They're some sort of micro-entity that's inextricably tied to term bundles (i.e. vocabularies...) but this is odd because an entity can have a "type" like nodes have types. In this way we attach different fields and such, but terms, despite being segmented in this fashion, seem to have an additional, largely useless, secondary entity layer tied in. I have yet to get an acceptable answer on why this was done. However, its presence has given others ideas that these configuration entities are good and useful, but core is truly unprepared for this eventuality, and while I would support the optional use of entities for configuration, if the api supported it as well, the api does NOT support it very well and thus contrib is left to figure out the missing pieces.

TL:DR

Let's not use entities for non-user-facing-data. I think that core entity api is too immature for it, and we'll have a hard time forcing the missing pieces onto the contrib world without a lot of proof that we're right.

fago’s picture

Core implements entities for nodes, users, terms, vocabularies, and I think that's it.

Files are entities too (and comments).

Vocabularies are where issues start to get fuzzy. They're some sort of micro-entity that's inextricably tied to term bundles (i.e. vocabularies...) but this is odd because an entity can have a "type" like nodes have types. In this way we attach different fields and such, but terms, despite being segmented in this fashion, seem to have an additional, largely useless, secondary entity layer tied in. I have yet to get an acceptable answer on why this was done.

I guess, because it's just handy. Why bother re-inventing wheel if we have an API for that?

However, its presence has given others ideas that these configuration entities are good and useful, but core is truly unprepared for this eventuality, and while I would support the optional use of entities for configuration, if the api supported it as well, the api does NOT support it very well and thus contrib is left to figure out the missing pieces.

Yes, core hasn't any dedicated configuration support, so we have to figure it out anyway.

Let's not use entities for non-user-facing-data. I think that core entity api is too immature for it, and we'll have a hard time forcing the missing pieces onto the contrib world without a lot of proof that we're right.

We'll never have a proof whether something is right or not. I don't see any drawbacks in using the entity API for configuration, so why not? Using the entity API for both, enables us to unify and re-use our CRUD API, while we can implement configuration or content specific functionality on top of it.

But yes, I agree that a way to distinguish "configuration" entity types and "content" entity types, might be helpful - but that line isn't easy to draw.

EclipseGc’s picture

But that line is VERY necessary. Within page manager we have entity contexts available, and that's useless for configuration entities, but I have no method for removing them from my loops without manually doing something for each entity system that is used for configuration.

In so much as how vocabularies relate to this, I think my point was that they're entirely unnecessary. We have no need of that entity (as far as I can tell). That being said, I think its existence provides a bad example in core.

I think the difference, as to how this conversation relates to ctools and entities (core and contrib) is that within ctools, we have methodologies where we focus the developer on their schema, and we build the user interface form them. (export_ui) In this case, said developer gets configuration exporting and a generic user interface (which they can extend if needed) for nearly free. Entities, on the other hand, were intended for content. The fact is that they are being used for configuration though, and no matter how much I whine or complain, this cat's not going back in the bag, so we need to come up with some methodologies to allow the best scenario for this fact of life to play out.

Eclipse

amitaibu’s picture

> In so much as how vocabularies relate to this, I think my point was that they're entirely unnecessary. We have no need of that entity (as far as I can tell). That being said, I think its existence provides a bad example in core.

I disagree, as I have a use case that I miss vocabulary actually not being fieldable -- OG-vocab module. Now that OG is working with fields, if vocabulary was fieldable I could assign the OG field to it, and reduce og-vocab logic at least by half.

Regrading the issue itself I actually think, that we should wait some more time to see how indeed the Entity API matures and get real life use cases. Right now it seems we are kinda looking for a solution for a problem that isn't there (or at least isn't very big).

merlinofchaos’s picture

Status: Active » Closed (duplicate)

http://drupal.org/node/681362

This is mostly the same tenor of conversation, so marking htis a dup of the older issue. No need having multiple issues open about the same thing.