Entity API as dependency (was Rules integration for atom CRUD events)

No we don't have it now. We can either explicitely integrate with Rules or implement an Entity API interface to have that integration automatically. But it is tricky to have optional interface implementation because Scald is not depend on Entity API.

Here's a patch to add rules support for the insert, update, presave and delete events on atoms. It's based on the node module's integration with rules.

Instead of adding a lot of code, can we just leverage on Entity API for the CRUD events integration? Even if we must depend on Entity API, I don't think this is a problem at this time.

For the Entity module to handle Rules integration, the controller class ScaldAtomController would have to implement EntityAPIControllerInterface. That's normally done by extending EntityAPIController rather than DrupalDefaultEntityController. Is that something you want to do? It does have some other benefits but is a more fundamental change.

Yes, it is (by "if we must depend on Entity API"). We can even then remove more code.

It is a more fundamental change, but won't have any backward compatible problem. I don't know any D7 site built in the last year that does not use Entity API.

I've got a bit of time available this week to help with a re-write. Has anyone started work on changing the controller class yet?

New patch attached. Here's a summary of the changes made:

ScaldAtom does not have the right construction parameters to work with Entity API. So now ScaldAtom just extends ScaldAtomEntity, a new class that extends the Entity class and is used as the entity class in hook_entity_info(). If we could remove/deprecate use of "new ScaldAtom()" in favour of a wrapper "entity create" function then this extra class could be dropped in the future.

ScaldAtomController now extends EntityAPIController

Save method removed from ScaldAtom since now provided by Entity class, and ScaldAtomController::save no longer static since not compatible with EntityAPIController

scald_atom_save() now uses entity_save() since ScaldAtomController::save no longer static

"save callback" removed from hook_entity_info() since expected return values for CRUD API not returned by scald_atom_save plus it's superseded by changes to save method on ScaldAtom class

Now ScaldAtomEntity extends Entity, we can drop "create callback" entity property key in favour of default CRUD API behaviour

Changed ScaldAtomController->save to draw upon new parent class, reducing the amount of code needed.

Removed "delete callback" in hook_entity_info() and moved logic from scald_atom_delete_multiple into ScaldAtomController to use the Entity CRUD API

Removed "view callback" since parameters don't match Entity API. Moved scald_render_multiple code into ScaldAtomController->buildContent so entity_view() can be used.

Serialized fields are handled by the Entity API so no need for ScaldAtomController->attachLoad() any more.

Now extending EntityDefaultViewsController with ScaldAtomViewsController so scald_views_data not needed. This also means field naming etc now consistent with scald_entity_properties_info()

Views api updated to 3 since this is what's supported by EntityAPI. The hook_views_handlers() not used in Views 3 so the file includes/views.inc no longer required.

Option lists for atom type and providers now handled by EntityDefaultViewsController. Updated hook_entity_property_info() with "options list" key for providers using a new callback function scald_atom_providers_options_list() to mirror what was done with the existing scald_type_get_names() function.

Default Rules support through Entity CRUD API is now available.

8: rules_integration-2089865-8.patch queued for re-testing.

3: rules_integration-2089865-3.patch queued for re-testing.

8: rules_integration-2089865-8.patch queued for re-testing.

These tests are passing for me locally. Can anyone spot why they are failing here?

function scald_render_multiple($atoms, $context) {
-  $output = array();
-  foreach ($atoms as $atom) {
-    $output[] = array(
-      '#markup' => scald_render($atom, $context),
-    );
-  }
-  return $output;
+  return entity_view('scald_atom', $atoms, $context);
 }

You should not return "entity_view" inside of "scald_render_multiple" because it will cause recursive call of "entity_view".

See https://www.drupal.org/node/2424189#comment-9610717 for scald_render_multiple fix.

This could use some further development taking into account the current dev's status. Maybe after 1.4 release.

But we cannot just simply delete the views integration unfortunately, cause then all the existing views would be broken.
So we will need to keep the views integration in a legacy module that we enable with update hook, or we need to make some complex update hook to deal with that, or have to switch to 2.x to implement this.