Feature Proposal: TWiki Applications using variable setting import and form mapping

Motivation

You may have multiple instances of a TWiki application on a single site. In that case, it's desirable to have only one copy of the application being referred to by multiple instances instead of having multiple copies of the application. When a bug is fixed or an enhancement is made, if you have only one copy, all you need to do is to change that copy. Otherwise, you need to fix multiple copies.

Description and Documentation

A way to use a TWiki application

Here's a way to have a TWiki application used by multiple users.

• If a user wants to use an application, she "installs" it on her web as a subweb.
  • The installation is a subweb creation based on the template web of the application.
• In the application template and the copy of the user don't have the application implementation. They are referring to the application "code" somewhere else.

Maybe above is too abstract and difficult to understand. So let's think about a bulletin board application.

• Each posting is a topic and articles are displayed in the reverse chronological order.
• There is an Apps web having TWiki applications.
• The bulletin board application's code is in Apps/BulletinBoardImpl (impl for implementation) subweb.
• The app also has Apps/BulletinBoardTmpl subweb having the template for installation.
• The infrastructure team has the "Infrastructure" web for them.
• The team wants to use the bulletin board application. So they created Infrastructure/BulletinBoard subweb based on Apps/BulletinBoardTempl

The goal

There are missing features to make this scenario a reality. And this proposal is to implement those missing pieces.

A TWiki application consists of

• TWiki topics providing user interfaces
• TWiki variable definitions used on all topics of an installation
• TWiki forms

Of those, referring to a topic in the Apps/BulltinBoardImpl web doesn't need an enhancement. It's only a matter of:

%INCLUDE{Apps/BulletinBoardImpl.%TOPIC%}%

Most topics in Apps/BulltinBoardTmpl are like this.

Web-wide variable setting at somewhere else than WebPreferences

For variable definition, an enhancement is needed. Currently, the only way to set a variable for all topics is to set on WebPreferences. This means that without an enhancement, variable settings needed for the bulletin board application need to be done on Infrastructure/BulletinBoard.WebPreferences, which we want to avoid.

Here's the crux of the enhancement I'm proposing.

• After reading WebPreferences of the current web for variable setting, check %WEB_EXTRA_PREFS_TOPICS%. It may have a comma separated list of topics. If it's set, read those topics for variable setting as if they were WebPreferences.

For example, Infrastructure/BulletinBoard.WebPreferences would have:

   * Set WEB_EXTRA_PREFS_TOPICS = Apps/BulletinBoardImpl.VarDefs

This way, Infrastructure/BulletinBoard.WebPreferences doesn't have to have variable settings needed for the application.

On Apps/BulletinBoardImpl.VarDefs, you would have:

   * Set IMPLWEB = Apps/BulletinBoardImpl

And then topics on Apps/BulletinBoardTmpl subweb would have:

%INCLUDE{%IMPLWEB%.%TOPIC%}%

By not hard-coding the web name of the implementation, you get additional flexibility. You may enhance the bulletin board application. Before you "deploy" it, you need to have it tested by some users. For that, you would have the new version on Apps/BulletinBoardImplNew having

   * Set IMPLWEB = Apps/BulletinBoardImplNew

For the infrastructure team to try it out, all they need to do is to change Infrastructure/BulletinBoard.WebPrefereces to

   * Set WEB_EXTRA_PREFS_TOPICS = Apps/BulletinBoardImplNew.VarDefs

After confirming the new version is working as expected, the owner of the bulletin board application would change Apps/BulletinBoardImpl web to Apps/BulletinBoardImplOld and Apps/BulletinBoardImplNew to Apps/BulletinBoardImpl after changing IMPLWEB definition as follows.

   * Set IMPLWEB = Apps/BulletinBoardImpl

WEB_EXTRA_PREFS_TOPICS is not only for TWiki applications. If you have multiple top level webs and you want to configure them similarly, you can use the feature.

Referring to a TWiki form on a different web

The last obstacle is TWiki forms. To achieve the goal, each application instance needs to refer to TWiki forms in Apps/BulletinBoardImpl, which is possible but that's not enough. As long as a topic employs a form statically, you cannot switch to a new version easily. PickingFormDefinitionDynamically provides the flexibility needed.

Examples

Impact

Implementation

-- Contributors: HideyoImazu - 2012-11-02

Discussion

This proposal is related to TWikiAppInstaller, the spec of the app installer should reflect the needs you have.

Interesting how you come to a similar solution we used at Twiki Inc for apps. We created the app logic in the read-only TWiki web. Dashboards, discussion forums and other apps were distributed in user webs. Those app pages are a simple %INCLUDE{$SYSTEMWEB%.%TOPIC%}%.

This topic has two feature proposals, it might be better to track in two separate feature topics.

1. Read additional TWiki preferences settings from preferences settings path: This could be useful as noted. I think for TWiki apps it not needed as long as you use SetGetPlugin variables instead of preferences settings. You can INCLUDE SetGetPlugin variables in your app pages. They are as flexible as preferences settings, and they can be used in many places with INCLUDEs, e.g. you don't run into the preferences path issue.

If you follow-up on preferences settings path: Make sure the FINALPREFERENCES are final.

2. Referring to a TWiki form on a different web: This is already possible and actually in use. By default, the UserForm is taken from the TWiki web unless the admin defines a customized form and template in the Main web. The %META:FORM{}% can contain name="SomeForm" or name="Otherweb.SomeForm". Does that meet your needs?

-- PeterThoeny - 2012-11-05

I wasn't aware of TWikiAppInstaller. Thank you for the heads-up. This topic should be like the TWikiAppInstaller topic in nature - proposing a scheme rather than individual features/extensions needed to implement the scheme. I've created two proposals ImportWebPreferences and PickingFormDefinitionDynamically for the extensions needed while changing the topic name and title to a more appropriate ones.

It's true that if you use SetGetPlugin, you don't have to extend TWiki to make it possible to import variable settings from a topic. Still, there are practical merits in variable setting import especially with an application occupying an entire subweb and having multiple user interface topics.

1. Using variable setting import, individual user interface topics don't have to "include" variable setting.
2. %VARIABLE% is less cluttered than %GET{VARIABLE}%. Besides, %INCLUDE{%APPWEB%.BulletingBoardSettings}% needs to be put inside an HTML comment at the top of a topic, which makes things less beautiful.

%META:FORM{name="Otherweb.SomeForm" ... }% does not make FORM_MAPPING unnecessary because you cannot have a variable in the form topic name. Switching to a different version just by changing one variable cannot be achieved without FORM_MATTING allowing variables.

-- HideyoImazu - 2012-11-06

Peter, what exactly is the preferences path issue?

-- HideyoImazu - 2012-11-06

I replied in ImportWebPreferences.

-- PeterThoeny - 2012-11-07

One clear advantage of variable setting import over SetGetPlugin for TWiki applications is a TWiki variable can take parameters while values SET'ed and GET'ed cannot.

-- HideyoImazu - 2012-11-07

Let's have the conversations in the proper feature proposal buckets.

-- PeterThoeny - 2012-11-07

Closed at JerusalemReleaseMeeting2012x11x09, because handled in separate proposals.

-- PeterThoeny - 2012-11-09