Allow filtering of widgets available by page type

[nicolaas]

Hi

Hi Silverstripers

Widgets are a fantastic idea, but in the documentation they are listed as if the widgets were part of the blog module perse. In the documentation, I have added a section "how to add widgets to other pages": http://doc.silverstripe.com/doku.php?id=widgets#adding_widgets_to_other_pages

What is the philosophy on widgets - should all loaded widgets be available to all pages - or should widgets only be available to blog holders or ....?

For me, I would like to see the following:

Class MyPage? extends Page {

static include_widgets = Array( "mywidget1", "mywidget2", } }

see: http://www.silverstripe.com/extending-hacking-silverstripe-forum/flat/53193 Cheers

Nicolaas

[sminnee]

The whole point of widgets is that CMS authors can specify the functionality without needing to edit the code. So having a static variable defining which widgets are on that page would be counter-productive.

Instead, we would envision a system where each page or each page type would have a widget selector. It's still unclear how you would apply widgets to multiple pages:

• Every page has its own widgets
• Every page type has its own widgets
• Every page has its own widgets, with a default option to inherit from the parent

The 3rd option (inherit) is probably the most likely choice. It will be really important to have an intuitive user-interface for this, because widgets are more complex than "regular content-editing".

The target release for this is 2.2.3. (Or possibly 2.3 if we don't make a 2.2.3 release). I think that the default release would have space for a single feed of widgets to be shown in addition to the sub-navigation.

This will also mean that themes need to be upgraded to fit the widgets in.

[nicolaas]

I think I did not explain myself properly. The PHP coder should not determine what widgets are on what page, but what widgets are available to be added on what page type. For example, having the blog archive widget available on anything but the blog-holder is counter-intuitive. Some pages should allow the addition of widgets and other ones should not. I made a website for someone with a blogholder, but I also wanted them to be able to make a donation button on other pages without having to wade through all the blog widgets to find the donation widget.

At the same time, the developer could also set whether the widget should be applied by default to a certain page. Example: "add youtube video widget". Usually, the website owner, would want to add that only to individual pages where required. Thus the dev. adds it to the Page Class as an optional widget. However, if there is a section on the website called "video responses" then the widget would be added by default to all new pages in the video response section.

I would be able to help out getting this up and going, as I feel it is a great addition to Silverstripe.

Nicolaas

[sminnee]

I think that a better way of doing this would be to define a method on the widget that gets passed a page and returns true if a widget of this class can be added to the page.

<?php
class TagCloudWidget {
  function canAddToThisPage($page) {
    return $page instanceof BlogHolder;
  }
}
?>

That would mean that developers of new widgets can determine what kind of pages they can be used with. And, since we have a method rather than a static variable, the widget could check for the presence of a particular variable or relation (eg, does this page tpye a "Tags" field?) or that the object implements a certain interface, rather than a particular class.

The method would be designed to be called on a singleton() of the widget class.

[sminnee]

"However, if there is a section on the website called "video responses" then the widget would be added by default to all new pages in the video response section."

I'm not sure that default widgets like this are a good idea. It sounds like if you were making a site with functionality that was this well specified, then you would probably be better placed to use custom fields on the page type, rather than including a widget by default.

Widgets are very powerful, but we need to be careful not to overdo it - one of the benefits of SilverStripe? is that the CMS is designed to be tailored to an individual site's requirements. Widgets give the author more control, but at a cost of increased complexity.

[sminnee]

I've updated the title to better reflect what we're discussing :-)