Some initial function scoping for Dashboard API elements. See the comments. In particular, I think we can abstract the 'Dashboard' concept using hook_dashboard().

Doing so will allow for the creation of user, group, and administrative dashboards while using the same underlying mechanism.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

agentrickard’s picture

FileSize
3.15 KB

File attachment died.

agentrickard’s picture

Status: Needs work » Needs review
FileSize
8.97 KB

Here is a proof-of-concept patch for hook_dashboard() that does not seem to break anything.

drumm’s picture

FileSize
4.49 KB

I think all of the menu items should stay in the menu hook if possible. Extensions can use hook_menu_alter() if they need to do anything inconsistent. hook_dashboard() should have only metadata. This incomplete patch has the concept, but the loader and permissions need to be abstracted.

agentrickard’s picture

Yes. Simpler == better.

I think we should dynamically alter the permission, though, and possibly the loader function.

+      $info['path'] .'/%dashboard_' . $type => array(
+        'title callback' => 'dashboard_page_title',
+        'page callback' => 'dashboard_page',
+        'page arguments' => array(1),
+        'access arguments' => array('access '. $type .' dashboard'),
+        'type' => MENU_CALLBACK,
+        'file' => 'dashboard.page.inc',
+      ),
...

+function dashboard_dashboard() {
+  return array(
+    'user' => array(
+      'path' => 'dashboard',
+    ),
+  );
 }

The idea of the original patch was to provide sensible defaults for these, and not force module's to implement hook_menu_alter().

Will mess around some more this week.

drumm’s picture

Yes, the permission and loader do need to be altered too. There can probably be a common loader that does all the work.

I think using hook_menu_alter() is okay. That's what it is there for and I don't like adding more layers than necessary. We either force modules to use the standard hook_menu_alter() or a new set of hooks. The dashboard menu should have sensible defaults and use metadata from hook_dashboard().

agentrickard’s picture

FileSize
7.33 KB

OK, I think this patch incorporates those notes.

I took one liberty. The 'widgets' callback, I renamed to 'gadgets' for consistency -- but it can be changed back.

However, I did insert a loader function into that path as well, since we will need to load the current dashboard to see what widgets a user already has, since there is no point in displaying 'additional gadgets' that are already in a collection.

drumm’s picture

Gadget/widget will be problematic. The current terminology was chosen to match the redesign prototype and OpenSocial on the inside. We are no longer using OpenSocial for gadgets since everything comes from *.drupal.org, which we trust to not send malicious JavaScript. OpenSocial may be implmented in the future, but is not a priority. I think it should be widgets all the way down, but that is another issue.

drumm’s picture

Status: Needs review » Fixed

Committed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.