You are here: Foswiki>Tasks Web>Item175 (22 Feb 2009, KennethLavrsen)Edit Attach

Item175: Create TWiki compatibility plugin

Priority: Urgent
Current State: Closed
Released In: 1.0.0
Target Release: patch
Applies To: Engine
Component: TWikiCompatibilityPlugin
Reported By: CrawfordCurrie
Waiting For:
Last Change By: KennethLavrsen
As discussed in RebrandingPlan we need a compatibility module for existing TWiki users to get them up to speed as fast as possible.

The ideal brief is that Users should be able to install Foswiki, change the Extensions installer to point only to and update and install anything, including core plugins.

The Plugin needs to:

Include and TWiki-specific doc topics

Even if these are only pointers to the true doc

Redirect references to TWiki-specific web names

(TWiki. and Main.) To their new brand-free name, Interwiki-style

not so simple - as its dependant on where the topics are, references to a SYSTEMWEB topic that is actually in the TWiki web needs to goto the right place.

Similarly for pub files. This will likely require some dirty regex post processing like the DistributedServersPlugin

Sven is trialing:
  1. a Foswiki::Store::_getHandler hack that changes topic handlers to TWiki web if it detects that the stored data does not exist in the original place
  2. change PUBURL to SCRIPTURL{viewfile} for any TWiki caused attachments? thus taking advantage of the getHandler hack?
  3. a restHandler that will recurse through the TWiki web, and create a remapping Hash for pub Urls (this might also be the faster way to deal with topics too)

Contain the TWikiTerminologyMap

DONE - uses configure based hash to do the equivalent to apache's non-redirect rewriteRule.


TWiki did the reverse. Should be as simple as a *Set, but that Set needs to be in SitePreferences

DONE in the plugins' earlyInit (TWIKIWEB->TWiki, MAINWEB->USERSWEB)

contain a twiki.tmpl

that does an TMPL:INCLUDE{foswiki.tmpl} DONE

Namespace mapping

The main requirement is that unreleased plugins should have as painless a time as possible. These plugins are known to depend on:
  • TWiki::Func
  • TWiki::Plugins
  • TWiki (they often use it)
They may also assume:
  • Main, TWiki webs
ACTION: check the source tree to see what published plugins have abused

For Perl source code compatibility, an aliasing of one namespace to another can be done using Package::Alias, which basically just assigns the typeglob for the original namespace to the alias namespace.

(Nice one, Isaac! Thanks for pointing Package::Alias out).

  • Looking at the documentation and reading the thread you linked to, the Aliased module is intended specifically to provide an alias for a class and not alias a namespace, so it won't serve the needs for the Foswiki project. The confusion referred to -- that the module is not automatically imported with use/require -- is not an issue in this case; the compatibility module only needs to ensure any references to the TWiki:: symbol table will redirect to the Foswiki symbol table, and in fact it should not import anything automatically. (Using Package::Alias is just a bit of syntactic sugar; I just looked for a module that prettied up assigning one symbol table to another.) -- IsaacLin - 19 Nov 2008 - 13:32
    • Thinking about it some more: To keep the use TWiki* statements for TWiki plugins as is, stub and TWiki/*.pm modules are needed; they would use the corresponding Foswiki module and then alias the namespace. (If a parent namespace is already aliased, aliasing the descendant namespace is not needed, but there is no harm, either, and the code is more straightforward.) -- IsaacLin - 19 Nov 2008 - 15:58

  • yep, I ended up using Package::Alias - CDot.

I attached a shell script that renames the existing TWiki namespace to Randomnewname when run at the root of a checkout. Should be a run-once, once we have the new name. Does not touch JS or CSS, only pm. pl, bin/*.

STATUS - CDot 19/11/2008
  1. I have moved the code namespace using the shell script in /trunk
  2. I have renamed the data/TWiki dir to data/System (it was easier than doing the move via data/Foswiki)
  3. I have recoded the plugins discovery so that configure must be run to discover a plugin. And when it is discovered, the namespace it is found in is recorded. So in theory it's possible to have a Foswiki plugin and a TWiki plugin with the same name both available, and select between them in configure.
I have moved the code on /trunk over to the Foswiki namespace.
  • TWiki plugins work, even ones that are just unzipped.
  • I changed to auto-enable the plugins you install that way.
  • There is no "automatic mapping" of an old LocalSite.cfg to the new type. Namespace sharing doesn't seem to work for reasons I can't fathom.
  • There is a new $Foswiki::cfg var {Plugins}{WebSearchPath}
  • Each plugin has a {Plugins}{plugin}{Module}
  • I had to disable the TWikiCompatibilityContrib, because it was rewriting references to the plugin topics in the TWiki web.
I fixed all the static strings and all the comments as well. I also moved the following into the Foswiki namespace:

The others I left where they are, partly to test TWiki plugins in Foswiki.
To skip the syntactic sugar and just assign one symbol table to another, no strict 'refs' needs to be in effect during the assignment (so the text string can be interpreted as a reference to the variable named in the string).

Regarding problems with reading configuration from legacy LocalSite.cfg files: Perhaps namespace aliasing is happening too late? It may not be feasible to load in a plugin to do the aliasing; there may need to be a special hook so this can be done during the compile-time phase. I know the aliasing approach seems to have been abandoned, but I think assigning one symbol table to another is a very concise way to do precisely what is needed.

-- IsaacLin - 20 Nov 2008 - 17:46

Javascript and CSS

For any Javascript code contained within the TWiki simulated namespace: Namespacing in Javascript is simulated by using a variable as the namespace. As variables for objects are actually references (like in Java), the Foswiki project can have two variables pointing to the same underlying object, providing access to its properties via two separate simulated namespaces. Please also refer to Tasks.Item116.

CSS is a rule-based language, and there is no way to say that all the rules for one set of selectors applies for another set except by explicitly specifying that second set of selectors for each rule. (The cloning of the selectors could of course be automated.) See Tasks.Item113.

Status 30 Nov 2008 - The perl code has now reached a level of maturity that this catch-all task shouldn't be used for checkins any more, so I'm shutting down this report and elevating Item113 and Item116 to Urgent. - CrawfordCurrie - 30 Nov 2008

ItemTemplate edit

Summary Create TWiki compatibility plugin
ReportedBy CrawfordCurrie
SVN Range TWiki-4.2.3, Wed, 06 Aug 2008, build 17396
AppliesTo Engine
Component TWikiCompatibilityPlugin
Priority Urgent
CurrentState Closed
Checkins distro:c66da3593061 distro:91a5a2c1ec32 distro:796752799e9a distro:4ce409554622 distro:cd9c3f9d9014 distro:a3df55658579 distro:9558530bbabd distro:315530321e56 distro:9d75be18946f Rev 814 not found distro:41304f2e0286 distro:9160b360a7a5 distro:caa811542639 distro:3e00bf400416 distro:3e7b4fb7d1ae distro:3886d90e516e distro:b6e6b169fcc8 distro:4ea07640c9e8 distro:5d671548a0ed distro:a5fb579d88a6 distro:208357e27371 SpanishTWikiContrib:ae15854f689d distro:15ce55a25307 distro:cbc074f9c255 distro:dc1d4c1462db distro:c8e11850fe34 distro:effe4fa01a0a distro:8052a4a9028f distro:e98e3b015abb distro:2afd6e1d3358 distro:898e26fe965a distro:0b6f95824c48 Rev 913 not found distro:eea412548cc7 distro:a46613b1a3b4 distro:9a5a8c1d2690 distro:ee41531a6aa6 distro:0df134ce5e04 distro:ac8dabdb6439 distro:ae452939e887 distro:f57a693d8299 distro:06065f9c2d83 distro:a6f92e5dcdab distro:e1bd64a65f3e ActionTrackerPlugin:902f0604c085 distro:ca7d584b1aa9 PublishContrib:1ed702aef42e distro:4d962b61623a distro:b8bc8caca44a distro:43498f207be2 distro:b9a116c84b28 distro:cdb293167b45 distro:b14abe39d8f8 distro:ae2a6543e292 distro:61f709e43ff8 distro:0a7c2653b6d8 distro:bcac8dfee8e1 distro:7bd7d800b215 PublishPlugin:7e06b2ae2da4 distro:2aa73bdbec95
TargetRelease patch
ReleasedIn 1.0.0
Topic revision: r87 - 22 Feb 2009, KennethLavrsen
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