Allow plugins to create new View types for reports in widgets

[greg]

In fact most of the Piwik widgets already have multiple "pages". The first one is the data table, the second is the extended data table and then followed by several charts (bar, pie) and the tag cloud. I think this is a very good way of providing multiple presentations to the same data and it would be take this feature a little further.

problem definition

By now the multi-page widget is implemented inside one view (ViewDataTable). As a plugin developer it is very hard to understand this implementation (at least it is hard for me) and it seems impossible to add new "pages" to existing widgets without hacking the Piwik core. Why not moving the multi-page widget implementation into the widget architecture?

proposal

Each widget is able to define one or many pages. If there is only one page, the output is simply printed into the widget container. But if a widget defines multiple pages, the widget autmatically displays ui elements to let the user change the page (currently the icon bar footer).

To define a mulitple-page widget, the developer has to provide the following information for each widget page:

• id (unique inside the widget)
• icon filename (displayed in the icon bar)
• translated title (displayed in the icons tooltip)
• controller function that renders the widget page

benefits

• It would simplify the process of writing new multi-page widgets for plugin developers a lot. Plugin developers wouldn't have to care about restoring the last opened page on new requests, etc.
• It would ensure that all multi-page widgets share consistent UI elements, which makes theming or future UI changes much easier.
• It could allow plugin developers to add new pages to existing widgets or to replace existing pages. It would simplify the process of integrating new representations like #1514, #1558 or #1560 into existing dashboard widgets.

[matt]

You mention having possibility for plugins to define new 'view types'. I think this would be doable by adding a hook in the viewdatatable factory for example, and having the datatatable footers load the new icon, translations, etc.

[greg]

Adding a hook in the viewdatatable would at least make it easier to add new views to the current datatable.

But I also thought about going one step further. The viewdatatable introduces a nice icon footer into many widgets used in Piwik. By now, this icon footer is not very reusable. In fact, if someone is going to write completely new multi-view widgets that integrate well in the current Piwik UI he would have to rebuild the icon footer by hand (including html setup and js functionality like auto-hide and last-view-saving). This is what I did while creating the map widget.

So my idea was to move the multi-view code from the viewdatatable to the Piwik core in a way that every new widget can easily create new views.

Another option would be to create an abstract multi-view widget which would be extended by the viewdatatable or any other new multi-view widgets. However, the UI logic for the icon footer should use a single codebase.

[Ilinsekt]

Unfortunately I have no time to do this myself, but here's the general idea:

you need to modify plugins/CoreHome/templates/datable_footer.tpl to somehow include custom icons (maybe another if, for example if $properties.customicons with a foreach), specifically the section {if $properties.show_all_views_icons}. The format attribute of <a> is the one passed over GET and recognized by ViewDataTable::factory, the var attribute tells the javascript which button to display when the icons are grouped and this one is selected.

You then need to modify ViewDataTable::factory to maybe check if the class passed over GET exists, if yes return a new object of that class, else revert to default. Also a new method to add custom icons is required, it would set $this->viewPropertiescustomicons? to an array of the specified icons.

Your plug-in class (the one returned by ViewDataTable::factory) needs to have one method

protected function getViewDataTableId()
{
   return 'something';
}

where something is the same string as in the var attribute of <a> in datable_footer.tpl

I think that's all you need to do, but I'm not sure.

[matt]

I agree with the concept, but you worked around nicely in #1558.

I don't think we will be adding this feature at this stage. Let's reopen the ticket if need be :)