There was a bit of discussion about an API change in http://drupal.org/node/639320 but I could not see any followup discussions.

After trying to implement hook_diff() for the first time, there now seems to be a very limiting factor in the current implementation. All field modules (well most) would have to mimic all of the same functionality to pull out their own field changes.

So how about changing this to include an hook_entity_diff() and a hook_field_diff_view() to generate the array of differences?

The two main benefits is that this would allow contrib to extend the functionality to other entities very easily and field maintainers would be able to easily implement diff support.

I've partially started this in #1365750: Generalize API and Integrate with core field types without really thinking ahead, but the proposed change would be something similar to this:

function diff_compare_entities() {
  // Pull out the entity type...??
  $diff = module_invoke_all('entity_diff);
  // As per #1365750: Generalize API and Integrate with core field types
  // Manual handle this code here or create a field_entity_diff() callback to handle fields.
  return $diff;
}

/**
 * Compares the difference between two entities.
 *
 * @param $type
 *   The type of entity (i.e. node, user, comment).
 * @param $old_entity
 *   The older entity object.
 * @param $new_entity
 *   The newer or current entity object.
 */
function hook_entity_diff($type, $old_entity, $new_entity) {
  return array();
}

/**
 * Implements hook_field_diff_view().
 *
 * Computes a string that represents a single field item for diff comparison.
 *
 * @param $entity_type
 *   The type of $entity.
 * @param $entity
 *   The entity being displayed.
 * @param $field
 *   The field structure.
 * @param $instance
 *   The field instance.
 * @param $langcode
 *   The language associated with $items.
 * @param $items
 *   Array of values for this field.
 *
 * @return
 *   An array of rendered string values for the $items, keyed by numeric indexes
 *   starting from 0.
 */
function diff_field_diff_view($entity_type, $entity, $field, $instance, $langcode, $items) {
}

The module could also define a diff view mode on behalf of all fields and this could be used to generate the diff string if not overridden by a field callback hook. This would prevents second guessing what the column structure of the field items were.

Comments

Alan D.’s picture

Status: Active » Closed (duplicate)
mitchell’s picture

Status: Closed (duplicate) » Active

One more thing:
Could a diff also be an entity?
* This would be an elegant solution to #1672836: Rules integration for Diff module.
* #1671484: Show number of lines changed on revisions page could be a useful property of an instance.

Alan D.’s picture

Version: 7.x-2.x-dev » 7.x-3.x-dev

I think that you would need a concrete diff object per say to do this... Since the goal is to be able to compare any entity type, either by revision or other entities, there would be an infinite possible combination of these.

But for this particular use-case, a Diff cache comparison of sequential revisions could be on the cards, and I guess that there is no reason for this not to be an entity. I know that the simple caching had issues with becoming stale (i.e. editing a revision), and also the possible non-linear workflow through the revisions could force false comparison results to actions too. (i.e. jumping around between revisions, vid = 1 > 2 > 3 > 1 > 3)

mitchell’s picture

Status: Active » Closed (fixed)

For the cache issue, see #925706: Diff caching.