Renderlist plugin development

I have previously made a suggestion to extend the renderlistplugin: Support.Question52 and Development.SupportHorizontalMenusThroughRenderListPlugin

I have implemented a horizontal menu as part of the renderedlistplugin and after some experimentation I decided to put some more thought in, because:

  • There are other formats I would like to implement.
  • I did/do not fully understand the semantics of the themes.

Below is how I understand the semantics. It includes the functional extensions I would like to add.

The format of rendered lists

Formats of rendered lists are a broad classification of the lists. They are:

  • tree - renders the list as a tree, using line graphics to link the branches of the tree. The tree format can use icons at the branches or leaves using a special syntax icon:IconName
  • icon - is a tree format, but the icons for branches and leaves are defined as part of the theme. To me it appears that tree is a special case of icon, with all the line graphics defaulted.
  • horizontal - Flattens a nested bulleted list to a linear list and presents it horizontally.
  • table - Flattens a nested bulleted list to a linear list and presents it as a table\n\nIn all cases, the actual presentation is determined by the theme the format is used in.

Suggestion: There is also the TreeBrowserPlugin. That could be implemented as the flextree format. (Or as tree, but that would not be backward compatible frown, sad smile )

The themes of rendered lists

Themes of rendered lists define the presentation of the lists. To define a theme, you set the theme variable:
  • Set name_THEME = format-name, other variables...

Themes for the tree format:

  • Set <name>_THEME = tree, <0/1 flag to suppress/show lines of first level>

Themes for the icon format:

  • Set <name>_THEME = icon, <0/1 flag to suppress/show lines of first level>, <icon width>, <icon height>, <spacer graph>, <T-line graph>, <I-line graph>, <L-line graph>, <icon image>

Themes for the horizontal format

  • Set <name>_THEME = horizontal, <0/1 flag to suppress/show lines of first level>, <separator>, <starting character to enumerate the list>

Themes for the table format

  • Set <name>_THEME = table, <0/1 flag to suppress/show lines of first level>, <tableclass>, <tablewidth>, <columnwidths>

Question: Is this how the semantics are intended?

Focus in rendered lists

The focus="text" removes the link from the bullet the focus is on and renders it in a particular style.

For the tree and icon format, the focus shows the hierarchy above the focussed item and the full tree below it.

For horizontal and table, the focus will display the focussed item without link and with the style defined by class="focus". That class should be defined in an active style sheet.

Question: other suggestions?

Final point

In SupportHorizontalMenusThroughRenderListPlugin Arthur makes the point: RenderListPlugin is one of the distributed extensions, so we apply a bit more scrutiny here.

What does that mean if I want to proceed along the lines suggested above?

Footnote

I am confused. I was referred here from the Feedback link in the Plugin Info box on the RenderListPlugin page.

I later found that there is the support hub for renderlist plugin at RenderListPlugin. Should I have put this there?

Or should I have continued this discussion in SupportHorizontalMenusThroughRenderListPlugin. It seemed off topic there.

-- BramVanOosterhout - 08 Mar 2009

A question on implementation

In MediaWikiTablePlugin I noticed an implementation that delegated the actual processing to a submodule Core.
sub handleMWTable {
  require Foswiki::Plugins::MediaWikiTablePlugin::Core;
  return Foswiki::Plugins::MediaWikiTablePlugin::Core::handleMWTable(@_);
}
The difference is (as far as I understand) that this mechanism forces the compile of Core only if Core is needed. Is this a recommended strategy. And if I proceed with the implementation of RenderListPlugin as described above, where there are multiple options, not likely to be all used on the same page, would it be worthwhile to use require and multiple modules (Tree, Icon, Horizontal, Table) as the approach in implementation? Instead of coding it all in Extensions.RenderListPlugin.pm.

-- BramVanOosterhout - 10 Mar 2009

Bram, we're trying to keep the Extensions web free of everything except uploaded extensions, and also focus support for extensions into the Support web. Most extensions have a topic in Support web, usually with the same name as the extension. I think this topic should probably be in the Support web and linked from RenderListPlugin....

-- CrawfordCurrie - 10 Mar 2009

Thanks Crawford, I have moved this topic to the Support web. As I say in the footnote above smile it is where it is, because the Feedback link on the RenderListPlugin page puts it there.
Feedback:      http://foswiki.org/Extensions/RenderListPluginDev
Should I change that link there? I looks like it is intended and consistent with other Extensions

-- BramVanOosterhout - 11 Mar 2009

Please go ahead and remove it; it makes more sense to have a single link on the plugin topic, in the table, that links to the support topic. It'll be a while before we manage to eliminate all the remaining bits of the (tm)wiki legacy.

-- CrawfordCurrie - 11 Mar 2009

I did and now I realise that I should probably have checked out, fixed and checked in. Is that right?

I did a search for Feedback on the Extensions web and found many hits.

Happy to do some of the legwork if it is useful. Should I create a task?

I must be a nuisance asking all these questions, but I really have very little experience in this area. Some of the modification policies say "contact author first". Should I just go ahead, create a task and o it for the list returned in the search? anything else simple I can do whilst I am at it?

-- BramVanOosterhout - 12 Mar 2009
Topic revision: r8 - 12 Mar 2009, ArthurClemens
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy