Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

Archive /

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

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

Rendering modules and widgets...


Go to End
Reply


16 Posts   5255 Views

Avatar
Sigurd

Forum Moderator, 628 Posts

19 July 2007 at 5:49pm

Edited: 19/07/2007 5:55pm

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
[url]http://www.silverstripe.com/google-summer-of-code-forum/flat/2713[/url], 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->renderaslayoutinstead();
or
flickrgallery->renderasvariable("myflickrgallery"); // means $myflickrgallery works

Now, this brings me onto [url=http://www.silverstripe.com/core-team-discussion/flat/2723?showPost=2723]another topic as well...[/url]

Avatar
Sam

Administrator, 685 Posts

19 July 2007 at 10:39pm

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... ;-)

Avatar
Ingo

Forum Moderator, 801 Posts

29 July 2007 at 2:19pm

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 :)

Avatar
Anonymous user

22 Posts

30 July 2007 at 1:32pm

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.

cheers,

Brian

Avatar
Andy

230 Posts

31 July 2007 at 11:04am

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.

Avatar
Sam

Administrator, 685 Posts

31 July 2007 at 4:22pm

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

Avatar
Andy

230 Posts

2 August 2007 at 10:06am

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

Avatar
Sean

Forum Moderator, 922 Posts

2 August 2007 at 2:55pm

Edited: 02/08/2007 3:11pm

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.

Cheers,
Sean

Go to Top