hook(s) for field- and node-handlers

Ok, my post wasn't that clear.

A module implementing this hook should have a chance to offer as many different conflict detection methods as it sees fit. Some of these conflict detection methods might only need to look at one field (and will probably be able to do so only for fields of a certain type), and some other conflict detection methods might have to consider the whole booking node, maybe in order to check for value combinations of several fields or whatever I don't know yet.

For example, two different implementations of the hook could look like this:

/**
 * Implements hook_resource_conflict_info().
 */
function my_first_module_resource_conflict_info() {
  $info = array(
    'conflict_detectors' => array(
      'detector_a' => array(
        'type' => 'field',
        'fieldtype' => 'nodereference', // As seen in DB table {content_node_field}.
        'conflict_detection_callback' => 'my_first_module_resource_conflict_detection_nodereference',
        'conflict_message_callback' => 'my_first_module_resource_conflict_message_nodereference', // Format a conflict message which is meaningful to the user. Maybe optional?
        'title' => 'Detector A', // optional
        'description' => 'Detects resource conflicts of nodereferences.', // optional
        'file' => 'my_first_module.callbacks.inc', // optional
        'path' => drupal_get_path('module', 'my_first_module') . '/includes', // optional
        // [...]
      ),
      'detector_b' => array(
        'type' => 'node',
        'nodetype' => 'booking', // As seen in DB table {node_type}. Maybe optional?
        'conflict_detection_callback' => 'my_first_module_resource_conflict_detection_node',
        'conflict_message_callback' => 'my_first_module_resource_conflict_message_node', // Format a conflict message which is meaningful to the user. Maybe optional?
        'title' => 'Detector B', // optional
        'description' => 'Detects resource conflicts of complete node.', // optional
        'file' => 'my_first_module.callbacks.inc', // optional
        'path' => drupal_get_path('module', 'my_first_module') . '/includes', // optional
        // [...]
      ),
    ),
  );
  return $info;
}

/**
 * Implements hook_resource_conflict_info().
 */
function my_second_module_resource_conflict_info() {
  $info = array(
    'conflict_detectors' => array(
      'textual_detector' => array(
        'type' => 'field',
        'fieldtype' => 'text', // As seen in DB table {content_node_field}.
        'conflict_detection_callback' => 'my_second_module_detect_text',
        'conflict_message_callback' => 'my_second_module_text_message', // Format a conflict message which is meaningful to the user. Maybe optional?
        'title' => 'Textual Detector', // optional
        'description' => 'Detects resource conflicts of text fields.', // optional
        'file' => 'my_second_module.callbacks.inc', // optional
        'path' => drupal_get_path('module', 'my_second_module') . '/includes', // optional
        // [...]
      ),
    ),
  );
  return $info;
}

For now, I would prefer to wrap the detection method definitions into that 'conflict_detectors'-sub-array to be able to extend this hook interface later with other sub-arrays. And I didn't have an idea yet whether to make a difference between single-value and multi-value fields or not, maybe it's possible to make really simple single-value field detectors like this:

/**
 * Implements resource conflict detection callback, single-value-field variant.
 */
function my_second_module_detect_text($field_value_a, $field_value_b) {
  return $field_value_a == $field_value_b;
}

And if I come to think about it, some conflict detectors will even have to see all the time-conflicting booking nodes which the resource_conflict-module found out so far, the pool-checking in #750520: handle "organic group" resources as a resource pool will be such a case, very probably.

/**
* Implements hook_resource_conflict_info().
*/
function pool_checker_resource_conflict_info() {
  $info = array(
    'conflict_detectors' => array(
      'pool_over_usage_detector' => array(
        'type' => 'node_collection',
        'nodetype' => 'booking', // As seen in DB table {node_type}. Maybe optional?
        'conflict_detection_callback' => 'pool_checker_detect',
        'conflict_message_callback' => 'pool_checker_format_user_message', // Format a conflict message which is meaningful to the user. Maybe optional?
        'title' => 'Pool Checker Detector', // optional
        'description' => 'Detects resource pool over-usage as a type of resource conflict.', // optional
        'file' => 'pool_checker.callbacks.inc', // optional
        'path' => drupal_get_path('module', 'pool_checker') . '/includes', // optional
        // [...]
      ),
    ),
  );
  return $info;
}

Here comes a "first draft" which is intended to replicate the original behavior only, but by implementing a hook and several callbacks.

As it turned out, the original behavior is of the "consider the whole node"-type (see #2), as it announces a conflict even if the same resource is referenced by different nodereference fields. (Imagine for example, a "course" node_type which can refer to teaching equipment [like beamers, and so on] as "field_teaching_equipment" and another node_type "service" which can refer to the same teaching equipment as "field_serviceable_object" [when service has to schedule to call in a beamer to change it's bulb, or whatever].)

"Still to be done" is handling of conflict detectors for individual fields and whole groups of overlapping nodes. (Both the original motivation to begin with hooks and callbacks in the first place.)

In the uploaded tar-file you can find a small additional module which implements the userreference conflict detector as seen in #749852: Add userreference as a type of "resource". I did this only because I already had an implementation to compare it with and to have more than 1 detector type (to learn to handle plural) and to have an example for an external detector module.

Maybe this resource_conflict is "polluted" with some patches from the issue queue. I am willing to sort this out finally, but IMHO I don't think this would be a real obstacle for having a "first look".

Documentation is lacking. Sorry for that, but I think I will be motivated enough to document if I get a little echo on this first draft.

Please have a look and tell me what you think!

"Second" draft, 2 bugfixes and removed some misleading defaults.

Draft 3, some bugfixes and heavy renaming / refactoring. It's scary how renaming only some variables gives a whole new perspective... ;-)