Preserve breadcrumbs on edit pages for Rules

Yep, we definitely need to solve this. The problem is that the path for editing a rules configuration is used from inside the "reaction rules" and the "components" tab, additionally I thought of allowing modules to re-use that paths too - such that modules integrating some rules UI don't have to re-implement all the menu callbacks.

So I'm unsure what's the right way to proceed, but maybe we just autogenerate the default breadcrumbs of Rules + add a hook "rules_ui_context_alter" that allows modules to alter the breadcrumb before it gets set based upon the Rules-configuration. That way a module could take over the rule-editing context for some configurations.

subscribing

Here is an attempt to solve the bread crumb issue and to decouple Rules and Rules Admin in a better way.
The idea: Use a static variable "basePath" in RulesPluginUI that indicates a base path of an overview page (e.g. admin/config/rules/reaction or admin/config/rules/components). The base path is passed via the hook_menu() implementation and preserved in $form_state, so that it is not lost on cached forms.

Furthermore this patch removes all path constants like RULES_UI_PATH from the UI files in Rules core, so that all third party modules can use the UI independently.
And this patch introduces a RulesUIController to make use of the Entity admin UI, currently only for specifying the hook_menu() items.

So ideally third party modules can embed the Rules UI like this:

/**
 * Implements hook_menu().
 */
function mymodule_menu() {
  $items = array();
  $items['admin/config/mymodule'] = array(
    'title' => 'My module',
    'page callback' => 'drupal_get_form',
    'page arguments' => array('mymodule_rules_overview'),
    'access arguments' => array('administer rules'),
  );
  $controller = new RulesUIController();
  $items += $controller->config_menu('admin/config/mymodule');
  return $items;
}

function mymodule_rules_overview($form, $form_state) {
  form_load_include($form_state, 'inc', 'rules', 'ui/ui.forms');
  RulesPluginUI::$basePath = 'admin/config/mymodule';
  $form['table'] = RulesPluginUI::overviewTable();
  return $form;
}

great progress!

+ * The base path determines where the Rules overview UI lives. All forms that
+ * want to display Rules (overview) forms need to set this variable. This is
+ * necessary in order to get correct operation links, paths, redirects, bread
+ * crumbs etc.

Hm, it tells us where *an* overview UI lives, thus where we need to be able to edit the rules configs. I think we need to make this clearer, such that people don't think the base_path will also generate the overview page for them.

$form['#after_build'][] = 'rules_base_path_handler';

The name of the handler should reflect which kind of handler it is. E.g. use rules_form_after_build_restore_base_path().

New patch:
* Tried to improve the $basePath comment, but it is not really satisfying yet.
* Renamed the form after build function.
* Removed all path constants. Now also the forms in rules_admin.inc are base path agnostic and get an additional $base_path parameter ==> better re-use for other modules.

Awesome!

+    // Components UI menu entries

Missing trailing point.

* Fixed the comment with the missing trailing point.
* Incorporated the changes from #990514: Porting Scheduler UI, rules_scheduler keeps its own hook_menu() for the schedule tab; the menu callback for manual scheduling is added to the RulesUIController.

Patch looks good + works great for me -> committed! Thanks!
Finally we have breadcrumbs.. yay :)

@rszrama: You'll have to update the DC rules UI stuff to add in rules-config menu items and to set the static path as outlined in #4. Please report if you ran into any troubles. :)

see #1015872: support contrib UIs even if rules_admin is disabled for a follow-up on that. The above approach of re-using the UI should still work, I tried to make it even easier though.