I've just ported the ctools exportables to the entity API, see #678220: Make entites exportable.

So it'd be nice if ctools is aware of exportable entites, so that e.g. the bulk export could also work with them. Patch attached.

Off-topic: ctools could need a 7.x branch for issues.

CommentFileSizeAuthor
exportable_entities.patch3.55 KBfago

Comments

sdboyer’s picture

sdboyer commented
Issue tags: +D7 porting

Thanks for this, but please don't slide in unrelated changes (changing the anonymous function call to use call_user_func()); it makes me distrust your patches :(

Yeah, I need to actually mark that the 7.x branch follows HEAD. ...and I need to get back on getting HEAD up to date on the port work (#589636: Port to Drupal 7). ugh. Tagged appropriately, though, for once I do it.

fago’s picture

fago
Primary language German
Location Vienna
commented

The call_user_func() is necessary for making it possible to use methods for callbacks. As I set the export method as default for entities if it exists, it's needed to let that work.

sdboyer’s picture

sdboyer commented

Hmm, my apologies, that is a good reason.

Now that I've gotten HEAD back up to date, I'll make sure to consider & review this properly when I next sit down to port work.

merlinofchaos’s picture

merlinofchaos commented
Version: 6.x-1.x-dev » 7.x-1.x-dev
merlinofchaos’s picture

merlinofchaos commented

Just updating this issue with http://drupal.org/node/938368

amitaibu’s picture

amitaibu
Primary language Hebrew
Location Israel
commented

Following a conversation with fago about Message module -- #795352: Drupal 7 - build upon entities?

Currently as I see it CTools and Entity API have some in common but they are walking on parallel path -- currently one needs to choose one over the other. I hope we can together find a solution that will allow modules (such as Message) to enjoy the power of entity (i.e. attach fields that opens the door for some rally crazy stuff) but still use CTools' plugins/ export-ui etc'.

As far as I can tell, on the most basic level of having CTools load/ save/ export enteties it doesn't really need to do anything since a load/ save/ export callback can be specified. So it's up to Entity API to declare the entity as exportable sing hook_schema_alter(). (I guess it could have been the other way around as-well, but I think that currently CTools is more widely accepted as the way to deal with exportables).

With that said, I think that it could be a nice feature for CTools to :
1) use entity_load() instead of db_query() if it recognizes the exportable as an entity.
OR
2) Automatically define each exportable as an entity (not necessarily fieldable), thus always using entity_load()

amitaibu’s picture

amitaibu
Primary language Hebrew
Location Israel
commented

fyi, #938610: Integrate with CTools exportable

fago’s picture

fago
Primary language German
Location Vienna
commented

>1) use entity_load() instead of db_query() if it recognizes the exportable as an entity.
Sounds like a way to go. I'd be happy to help with that.

>2) Automatically define each exportable as an entity (not necessarily fieldable), thus always using entity_load()
That is what the entity API already does and I'm advocating for. But please, let's avoid duplicate solutions, instead join forces!

amitaibu’s picture

amitaibu
Primary language Hebrew
Location Israel
commented

http://github.com/amitaibu/message/tree/DRUPAL-7--1
Things I learned from starting to port Message to D7 using CTools *and* entity API:

1) I really like entity it's powerful, and having fields is great. However, the UI of CTools is currently very flexibale. Just look at message_ctools_export_ui.inc and see how very little we need to define in order to get it working. Actually - admin/structure/message - is already (kinda') working.

2) CTools introduces the idea of plugins (and an include file for each plugin). I really like this idea, and wouldn't want to replace it with a custom solution.

So, for now Message module has 2 dependencies -- CTools and Entity API. The thing is that I don't think that Message module is a special case. Context could be in the same place, and some many other exportable modules that could benefit from being an entity and fieldable.

So maybe another possible solution, added to the ones pointed in #6 is to move entity.inc as an include inside CTools?

BenK’s picture

BenK commented

Subscribing... interesting discussion.

merlinofchaos’s picture

merlinofchaos commented

I still need to dig into entities to see where they ended up in D7, so it's hard for me to comment intelligently on this post.

I definitely would like to be able to take advantage of entities; that's something that's on my D7 port list. Obviously, getting something functioning has been a higher priority.

That said while I don't think export ui should depend on entities, I do agree that making it easy to attach the system to something that is also entities is a good idea.

Right now, export.inc is doing two things. Part of it is the exportability and part of it, in D6, has been adding CRUD as well. Those two things can probably be split apart, in some way. That, however, sounds very much like a D8 task, to me. We shall see.

fago’s picture

fago
Primary language German
Location Vienna
commented

>I definitely would like to be able to take advantage of entities; that's something that's on my D7 port list. Obviously, getting something functioning has been a higher priority.

I see. The entity CRUD API is ready to go (and has tests ;), so it might be worth trying to build upon entities now. You can make use of classes for that, or go with entity_|load|create|save|delete().

>That said while I don't think export ui should depend on entities, I do agree that making it easy to attach the system to something that is also entities is a good idea.
Sounds good. #938610: Integrate with CTools exportable might be the way to go here, we just need to find a way around that:

+            // FIXME: The following won't work, as CTools doesn't send argument
+            // entity_*() expects.
+            'load callback' => 'entity_load',
+            'export callback' => 'entity_export',
Right now, export.inc is doing two things. Part of it is the exportability and part of it, in D6, has been adding CRUD as well.

Yep, the entity CRUD API provides both as well. Integrating exportables with a CRUD API makes much sense to me.

So maybe another possible solution, added to the ones pointed in #6 is to move entity.inc as an include inside CTools?

I don't think it makes much sense to split the controller from the rest of the module, as you want to have all the helper functions around it. So if merlin 'd like to go that route, I'd suggest recommending the entity API as exportable solution in ctools + jump into entity API development. Of course, I'd very much welcome merlin as another maintainer. However, that way it's another dependency, which people don't like. But we have plugin manager in core now, so installing modules is easier. Then I think/hope the entity API will be rather widespread anyway with modules like Rules, Drupal Commerce, Profile2, Media, Search API and maybe others already depending on it.

merlinofchaos’s picture

merlinofchaos commented

I'd be interested in taking a look at entity.inc and possibly adopting it for CTools. Given that I do believe entities and export API are likely to grow together and work on a merge in D8, doing that makes a lot of sense, and it really fits the kind of tools CTools provides. I'll need to take a look at it.

mlncn’s picture

mlncn commented

Bump. Thoughts on what consolidation and consistency (in code and from the site builder's perspective) we can do for exportables in Drupal 7? My one thought on the matter (for D8, anyway) is to be able to flag what exportables are configuration and what are code in a use-case determined manner to aid deploying new features to live sites.

As for the practical short-term, can we move basic entity exporting out of Entity API and into CTools. I agree Entity API will likely be pretty widespread but CTools will be nearly universal, and if we don't need to automatically have two dependencies for any exportable entity that would be great.

[EDIT: Upon thinking a little more that seems unlikely-- Entity API exportables depends on Entity API CRUD, right? So barring a move of exportable capability to CTools, what do we do to have CTools' export interface play nice with entities?]