Hi there,

Since the last thread kind of died, ive decided to serve up my latest work on the Dashboard interface here rather than resurrecting a dead thread. For reference heres the old thread.

Anyway, i've decided to go ahead with the user todo list, with widget capability to be added. Ive coded up a fully working proof of concept which allows you to easily add Todo items to the page displayed when an Administrator logs in and have them display the items when they select it. Im probably babbling - so theres a screencast here displaying what ive done so far. (Warning: its 6MB). I also have a tar archive of my progress, along with install instructions etc. It can be found here. Please note that its completely untested.

Please Note: DO NOT INSTALL THIS ON A LIVE SITE! It will probably break something. Also - i know the add a widget button does nothing - hopefully it will sometime in the near future ;)

It'd be great if a few people could download and test the tarball on their local servers or similar, and give me some feedback/ideas.

Thanks.

For installing widgets, have a look at my sandbox widget, which allows you to install any widget available for download from SilverStripe.

Looks awesome man, good work, I'll install it tonight and give it a whirl,

The dashboard looks great! That's quite a compelling screencast. :-)

This looks very useful.

I could see there being benefit in making the generic dashboard system part of the cms core, and then creating a host of modules for plugging various pieces of information into it. For example, the statistics system is going to be spun out into a separate module for 2.3, so it would make sense to include the statistics plug-ins with that.

Currently you have a plug-in system for to-do items, which is a good start, but I think that the other information, such as most popular pages, should be pluggable too. It looks like you're pushing in this direction yourself.

I see that you've created a "DashboardWidget" class; I wonder whether there is sufficient difference between dashboard widgets and front-end site widgets to justify the 2nd API? It would be nice if we could minimise the number of different APIs there were. If nothing else, I would point out that we already have an RSS widget that you could re-use ;-).

Nicolaas and I discussed an extension to the widget system to make widgets more aware of the context in which they are being used - http://open.silverstripe.com/ticket/2376. This would be an alternative way of saying "this widget can *only* be used on the dashboard". However, may widgets - such as number of page views - would quite likely have a place on the front-end site.

If you think about intranets - site admins might have the need to set up a private page loaded with content very similar to your CMS dashboard. Using the built-in widget system would allow for that nicely.

There will doubtless be issues with the *current* implementation of the widget system, but I would say that we would be pretty supportive of merging in any patches to the widget system that you submit as part of this. The most likely release would be version 2.3.

Hi Sam,

At the moment I’m working on the widget system, and will hopefully upload a quick demo when I get home. As for the second widget API, I’m using DashboardWidget (extending Widget) to parent all the widgets - all this does at the moment is add a has_one linking the widget to a member. I’ve made a note to myself to refactor this into a simple DataObjectDecorator, hopefully ill get around to doing this very soon so all front-end widgets will be easily pluggable in to the backend. Ticket #2376 will be useful to restrict widgets to certain areas, so frontend/backend only widgets don’t explode when added to the wrong place ;)

Another note so I don’t forget is that if the backend widgets will be used in the frontend, then ill have to ensure that you can add dashboard widgets without the has_one member requirement.

As for making other content pluggable, I’m currently thinking about adding a similar function to the addTodo method, but allowing you to specify a filter and add the item to the site information box rather than the Todo items box. Maybe also a DashboardTodo::addCustom function to add things like Top Search Terms, rather than hardcoding it in.

Just a quick note on how I’ve implemented widgets:
All Dashboard Widgets currently extend from DashboardWidget, to be later refactored into a decorator. Each dashboard widget has one member, and each member can have many widgets. At the moment, to add a widget you click the "Add a widget" button, and a form asking you to select a widget pops up using GreyBox. Once you have selected this it calls getCMSFields on that widget to get all the input needed. After you save the widget the widget area reloads its information with an Ajax-Call. Each widget also has a delete button in the top right, later to be supplemented by an edit button so you can edit the widget without deleting it. (Dropdown menu?)

Hi Grayzag,

Another way of approaching the widgets would be to create a separate WidgetArea object for each CMS admin - the regular widget system groups Widgets into WidgetAreas.

You could add Member.DashboardWidgetsID to point to the appropriate WidgetArea. It should then be possible to leverage the current widget editor for the purposes of editing the dashboard.

This will keep separate the concerns of showing different widgets to different CMS users, and the actual rendering of those widgets.

The other thing I would suggest is that having different widgets for different CMS users is kind of a low-priority issue, simply because most sites have relatively few people who log onto the CMS. You could therefore build the system to just use a single WidgetArea, and then add member-specific WidgetAreas later without having to change the actual widget-display code too much.

Hi Everyone,

Heres a basic implementation of the widgeting system, using a Member decorator to link each member to a DashboardWidget_Area object (later to be refactored into a plain Widget Area). Thanks very much for all the help simon_w and Sam, and thanks to Sean and Will for your feedback.

Anyway, theres another screencast (4.5MB) showing the functionality. If you want to grab the source its right here.

Thanks.