namespace for plugins (ticket #735)

[FND]

All,

It would be desirable to provide a namespace (see below) for plugins to
register their functions and variables:
http://trac.tiddlywiki.org/ticket/735

While there is a namespace for macros (config.macros), there's currently
no equivalent for plugins.

So we should provide an empty object that plugins can hook into, e.g.:
plugins.FooPlugin = {
cfg: [ ... ],
func: function() { ... }
};

Note that I've chosen "plugins" for the namespace here. Of course that
could also be config.plugins (or config.extensions, for consistency with
version.extensions?) - however, I feel that this doesn't really belong
into the config namespace.

There's also the more general question whether using objects for
namespacing is the right thing to do - are there any alternatives?

-- F.

[Martin Andreas Eines]

On Wed, Aug 20, 2008 at 12:42 PM, FND <FN...@gmx.net> wrote:
>
> All,
>
> It would be desirable to provide a namespace (see below) for plugins to
> register their functions and variables:
> http://trac.tiddlywiki.org/ticket/735
>
> While there is a namespace for macros (config.macros), there's currently
> no equivalent for plugins.
>
> So we should provide an empty object that plugins can hook into, e.g.:
> plugins.FooPlugin = {
> cfg: [ ... ],
> func: function() { ... }
> };
>
> Note that I've chosen "plugins" for the namespace here. Of course that
> could also be config.plugins (or config.extensions, for consistency with
> version.extensions?) - however, I feel that this doesn't really belong
> into the config namespace.

My vote is for an'extensions' namespace - in other words, exchange
'extensions' for 'plugins'. This way the consistency with
version.extenions is kept.

> There's also the more general question whether using objects for
> namespacing is the right thing to do - are there any alternatives?

I do not believe so (as far as my limited understanding of JS goes).

[FND]

> My vote is for an'extensions' namespace - in other words, exchange
> 'extensions' for 'plugins'. This way the consistency with
> version.extenions is kept.

We discovered one significant issue yesterday: Global variables should
be sufficiently "convoluted" to prevent clashes with local variables -
consider this:
if(!extensions) {
var extensions = {};
}

extensions.foo = {
do: function() {
/* ... */
},

onClick: function() {
/* ... */
// access global scope
extensions.do() // "this" is not suitable in this context
// create variable in local scope
var extensions = [".txt", ".html", ".xml", ".json"];
/* ... */
}
}

So maybe we should go for config.extensions/plugins after all?

-- F.

[FND]

> So maybe we should go for config.extensions/plugins after all?

Since there don't seem to be any objections, we've implemented this now:
http://trac.tiddlywiki.org/ticket/735#comment:2

The term "extensions" was chosen over "plugins" because it's more generic.
Also, looking at the objects in the existing "config" namespace, it
turns out that's exactly the place where this needs to be.

-- F.