Target Web for Plugins

Increasingly there exists Plugins that need their own dedicated web. (e.g. ProjectPlannerPlugin). At present they often contain instructions to get the administrator to copy the topics to a target web.

Question is: is this the right thing for them to do? If so, there needs to be an easy way for the plugin to provide its template topics. Should the plugin owner bundle a template web (i.e. one starting with an _ like the _default web? If so, how should it be named? _PluginName?

-- MartinCleaver - 20 Sep 2004

It seems like a good idea: provide a template web that starts with a _ named after the plugin (_ProjectPlannerPlugin, _XpTrackerPlugin), so the admin can create a new web using them as templates.

I second that.

-- RafaelAlvarez - 20 Sep 2004

Some way to merge with other default webs might be helpful. It could be the _default web is already set up with a corporate look & feel etc.

-- SamHasler - 20 Sep 2004

We need to distinguish between:

1. Plugins that need just one dedicated web
   • Can ship with a FooBarPlugin web
2. Plugins that provide a set of topics that is the base for multiple webs
   • Can ship with a _FooBarPlugin template web that gets instantiated when needed
3. Plugins that provide a set of topics (e.g. FooBarPluginStats, FooBarPluginSummary, FooBarPluginDetail) that is the base for a basename topic (e.g. for MyProj basename it will be MyProjStats, MyProjSummary, MyProjDetail)
   • Can ship with the set of topics in the Plugins distribution web (typically TWiki web). Ideally, all topics names should contain the name of the Plugin to avoid namespace pollution

-- PeterThoeny - 23 Sep 2004

Not the same topic, but you will see why I found this topic: more and more plugins really should be distributed with their own web, or, more precisely, a sub-web of the Plugins web (or TWiki.Plugins web).

Historically plugins have been asked to constrain themselves to only a single page in the TWiki web: FooPlugin.

This works fine for simple plugins. However, some plugins really need several pages: for example, TreePlugin really needs an example web of its own to test itself. Same goes for any of the other plugins that look at multiple files in a web.

-- AndyGlew - 16 Mar 2006

The topics intended for testing can be shipped in the Sandbox web, or in the TWiki web (with names identifying the Plugin.)

What we actually need is an infrastructure to install Plugins, Contribs and TWikiApplications from TWiki.org's Plugins web. What I envision is a web-based TWikiExtensionInstaller.

-- PeterThoeny - 16 Mar 2006

What XpTrackerPlugin does is to distribute a "template web", that can be used to create new webs for tracking.

The idea of a TWikiExtensionInstaller is quite interesting, though.

-- RafaelAlvarez - 16 Mar 2006

Saying that a plugin should install stuff in several webs - TWiki, SandBox, etc. - repeats the problems of UNIX, where stuff needs to be installed in ../{bin,lib} , etc.

I think UNIX folk have now realized that it is better to have package directories .../pkg/{bin,lib,man}, etc. This allows everything for a package to be located easily.

It also allows users to pick and choose what packages they install in their virtual paths. (Path length is not an issue for any reasonable shell/application - e.g. csh hashing.)

Their might be standard "virtual bins", or the like, assembled out of standard packages.

Anyway... I mention this because I think that you are repeating some of UNIX's evolution. (I've used UNIX since v6.)

Whenever you say something like "(with names identifying the Plugin.)" it means that you really need a directory.

-- AndyGlew - 18 Mar 2006