Jump to:

17452 Posts in 4473 Topics by 1971 members


SilverStripe Forums » Archive » Rendering modules and widgets...

Our old forums are still available as a read-only archive.

Moderators: martimiz, Sean, biapar, Willr, Ingo, simon_w

Page: 1 2
Go to End
Author Topic: 5133 Views
  • Sigurd
    Forum Moderator
    628 Posts

    Rendering modules and widgets... Link to this post

    Brian et al, something that may or may have been covered by the recent Themes Discussion (which please put highlights in a thread here) is allowing modules automatically work after a mere /db/build but also be capable of configuration.

    This will bear on all of the existing modules made, and needs to established in the next few weeks as the GSOC code comes into more shape. E.g. see
    http://www.silverstripe.com/google-summer-of-code-forum/flat/2713, where we now have modules returning their HTML into a template in different ways. We need a convention, and one soon.

    To my mind, there's a few ways a 'module' or 'widget' may wish to exist;

    1. Append to $Content. This could be the default option.

    2. Return as a dollar variable, allowing you to put $FlickrGallery or something anywhere in your templates

    3. As a /Layout/ file, which I think was a good scheme but was broken down in the rush to build the BlackCandy file. I feel as though Layout/Page.ss is "too big" and at this tage "layouts" are both trying to be most of a page, and a replacement or addition to $Content. Its role needs to be properly established.

    4. "As a widget" in which the location can be prescribed in the CMS or some easy manner. In essense, this is to allow putting it a right hand column of widgets akin to Wordpress, etc.

    5. None of the above, aka, let me manually put it somewhere in some other format.


    It might be that as a default it does #1 (for the time being, if #4 is some time off), simply so that the default case is a module that runs instantly with no template editing. You can then edit your mysite/_config.php a method that provides a clean way to make it render your module in a different manner, e.g.

    flickrgallery->renderasvariable("myflickrgallery"); // means $myflickrgallery works

    Now, this brings me onto another topic as well...

  • Sam
    679 Posts

    Re: Rendering modules and widgets... Link to this post

    Some thoughts...

    * #1 and #3 are two different forms of having a special page type to support the module. This works well for things like e-commerce where your module is "taking ownership" of a particular page or set of pages.

    * We should fix the "Layout" template scheme by more precisely defining what parts of the site should appear inside the Layout template.

    * Additionally, some templates will need to provide content to go on the outside of Layout. For instance, a shopping cart module might want to put a cart contents / checkout link at the top of the forum. Most likely, in addition to "Layout" we want some extra named-spaces in which we can put our stuff. For example, "UtilityInfo" could be an area at the top of the screen where we can put log-in info, checkout links, etc. The template designer could then choose a suitable place for UtilityInfo to appear.

    * For #2, we could add a method Widget($className) to SiteTree. It would instanciate and return $className. Your module could be implemented as a subclass of ViewableData. And you could then put $Widget(FlickrGallery) in your template.

    * #4 is a good idea that hasn't been explored much in SilverStripe. It would probably use the same kind API as #2 - that is, widgets could be inserted into the templates using $Widget(). Site/Template Developers would be able to set up one or more 'widget list' areas somewhere in their template - such as the right hand column - and have it populated by a corresponding 'widget editor' control in the CMS. In keeping with SS design principles, site developers could easily customise whether they had 0, 1, or many of these controls on their site, and have different settings on different page types.

    These will require some careful thought, and probably some core changes that will need to be part of 2.0.3. I'll going to be travelling the world for the next couple of weeks but will come back to it in early August. In the meantime, I'll keep an eye on this thread... ;-)

  • Ingo
    Forum Moderator
    801 Posts

    Re: Rendering modules and widgets... Link to this post

    from what i see, there are two types of widgets:
    1. global widget (e.g. a tagcloud) that just needs a page-context
    2. page-specific widget (e.g. gallery), where settings like thumbnail-size are specified on an instance-basis

    as we're relying on pagetypes to show config-settings, we need a more granular approach for #2. i like sams idea of specifying "widget-areas" in your Layout.ss, which are then populated in the CMS on page-by-page basis. we could solve this with a new API for a mini-getCMSFields().

    "global widgets" could still be configured in _config.php, until we get a proper UI for global settings. unlike #2, they could be inserted straight in the template, with the proposed Widget() template accessor.

    the tricky part is widgets which are supposed to be used global AND page-specific (e.g. a tagcloud might have optional page-specific settings as well). this again comes to building a config-API which can look up settings in the page-context (database), but falls back to global (_config.php).

    i think it would be appropriate to solve the issue with a new config API first (and on a broader level), and then get into page-specific widgets.

    when i'm back in germany, i'll dig up some examples how joomla/typo3/etc solve this problem

  • Anonymous user
    22 Posts

    Re: Rendering modules and widgets... Link to this post

    Lots of point here, so I'll summarize where we are now:

    - We're currently working on widgets and and API for them. We're at the widget API development point just now. When I say "we" I mean "me and Andrew".

    - The widget API is being driven by blog needs and GSOC needs.

    - Historically, there's been a tendency to over-design at SilverStripe. We need to be careful not to over-design the widgets API.

    - I don't see a need for global & page-specific widgets. That strikes me as over-design.

    - More specifically, there will be a 2-column layout in the cms where people can drag and drop from an available column to an "in use" column on a widget by widget basis. The "in use" widgets will go into a sidebar for blog. THis is an experimental interaction model, but one that I hope will work well. If it does, I think we can use it for more functionality of the CMS.

    - The main idea is simple, simple, simple. The intent is the API will have only the minimum amount it needs to get the job done.

    - The direction we're taking is along the lines of #2 and #4 above. That feels like a natural way to go and is where we were heading apart from this thread.

    - Andy, please read carefully through this thread and comment as appropriate.



  • Andy
    230 Posts

    Re: Rendering modules and widgets... Link to this post

    Currently, I am implementing #4 - that is, a page can specify a widget area, with an editor in the cms that allows you to specify which widgets are used, and configuration options using the 'mini-getCMSFields' that Ingo mentioned.

    #2 can be easily implemented by creating a method on the page controller, which can create a widget, set its config and then return it to the template.

  • Sam
    679 Posts

    Re: Rendering modules and widgets... Link to this post

    This all sounds really good, I look forward to seeing it when it's ready!

  • Andy
    230 Posts

    Re: Rendering modules and widgets... Link to this post

    I've documented what I've done for widgets (including using dollar variables) on the interal wiki at http://support.silverstripe.com/silverstripe/wiki/BlogModule#Widgets, which will be moved to the public wiki when the module is released.

  • Sean
    Forum Moderator
    921 Posts

    Re: Rendering modules and widgets... Link to this post

    In addition to your use of dollar variables in the documentation, can we not make a function for the controller like so:

    function Widget($widgetClass = null) {
    if($widgetClass && class_exists($widgetClass) && $widgetClass instanceof Widget) {
    $widget = new $widgetClass();
    return $widget->renderWith('WidgetHolder');
    } else {
    return user_error("SiteTree::Widget() could not find a widget class to create.");

    Then you could just go $Widget(FlickrWidget) anywhere in the template? Unless you've already done this, and I've missed something?

    EDIT: As Sam was saying, we'd just add this to SiteTree.


Page: 1 2
Go to Top

Want to know more about the company that brought you SilverStripe? Then check out SilverStripe.com

Comments on this website? Please give feedback.