Admin pages
agentrickard - April 13, 2009 - 20:43
| Project: | Dashboard |
| Version: | HEAD |
| Component: | User interface |
| Category: | task |
| Priority: | critical |
| Assigned: | agentrickard |
| Status: | needs work |
| Issue tags: | drupal.org redesign |
Description
Here is a patch that separates the admin pages for the various dashboards.
I think this is RTBC, but would like some feedback. The concept is that the second-level menu items (like /admin/settings/dashboard/default/block) will be used to limit the available widgets, whereas the main screen is a global on/off for widget types.
Note also the concepts of restricting the amount of content on a Dashboard -- this is crucial for performance.
| Attachment | Size |
|---|---|
| dashboard-admin.patch | 5.97 KB |
#1
Revised patch catches an error and splits hook_dashboard_widget() into an _info() hook and a data hook.
#2
#3
This is the same as above but makes makes the case of "Dashboard" consistent. It's a minor change but it beats saying "subscribe."
#4
Sorry, use this one. #3 was accidentally based on the original patch instead of #2.
#5
OK, I am ready to commit this patch, which includes a much larger change that separates Dashboard definitions and Widget definitions into separate include files and directories, Views and CCK style.
This will break things for a bit, but I think we need to bull forward.
Dashboard definitions now live in
module_dir/dashboards/name.incand Widgets live inmodule_dir/widgets/name.inc.Tested the new logic by moving the drupalnews widget into drupalnews/widgets/news.inc and changing drupalnews_dashboard_widget() to drupalnews_dashboard_widget_info().
Note also that individual admin settings pages for widgets are now optional, if you set $widget['settings'] => FALSE in your _info hook.
Having trouble with a patch file, so attaching the whole folder.
#6
tagging related issues
#7
I've been doing some housekeeping on this module. This looks like it will be the next thing to review sometime tomorrow. An updated patch would be great.
#8
It looks like a lot of this, like the widget includes, is duplicating what we want ctools content types to do.