mirror of
https://github.com/Jermolene/TiddlyWiki5
synced 2024-11-24 18:47:20 +00:00
2261fd4b84
It was getting a pain to manage the content in separate places, and I suspect confusing for end users. I think the best time to move the dev content out is when we’ve established the community wiki for TW5, which is a much more natural home for it. In the meantime, a feature that I’m interested in exploring is the ability to hide tiddlers from the UI based on tag. Then the tw5.com wiki could disable all tiddlers tagged ‘dev’ until explicitly overridden by the user.
43 lines
2.8 KiB
Plaintext
43 lines
2.8 KiB
Plaintext
created: 201308251429
|
|
creator: JeremyRuston
|
|
modified: 201310312218
|
|
modifier: JeremyRuston
|
|
tags: mechanism
|
|
title: BootMechanism
|
|
|
|
!Introduction
|
|
|
|
At its heart, TiddlyWiki5 is a relatively small boot kernel that runs either under Node.js or in the browser with all other functionality added via dynamically loaded [[modules|Modules]].
|
|
|
|
The kernel boots just enough of the TiddlyWiki environment to allow it to load and execute module tiddlers. The module system is compatible with CommonJS and [[Node.js]].
|
|
|
|
There are many [[different types of module|ModuleType]]: parsers, deserializers, widgets etc. It goes much further than you might expect. For example, individual tiddler fields are modules, too: there's a module that knows how to handle the `tags` field, and another that knows how to handle the special behaviour of the `modified` and `created` fields. Some plugin modules have further sub-plugins: the wikitext parser, for instance, accepts parsing rules as individual plugin modules.
|
|
|
|
!Plugins
|
|
|
|
In TiddlyWiki5, [[Plugins]] are bundles of tiddlers that are distributed and managed as one; [[Modules]] are JavaScript tiddlers with a module type identifying when and how they should be executed.
|
|
|
|
The tiddler [[$:/boot/boot.js]] is a barebones TiddlyWiki kernel that is just sufficient to load the core plugin modules and trigger a startup module to load up the rest of the application.
|
|
|
|
The boot kernel includes:
|
|
|
|
* Several short shared utility functions
|
|
* A handful of methods implementing the module mechanism
|
|
* The `$tw.Tiddler` class (and field definition plugins)
|
|
* The `$tw.Wiki` class (and tiddler deserialization methods)
|
|
* Code for the browser to load tiddlers from the HTML DOM
|
|
* Code for the server to load tiddlers from the file system
|
|
|
|
Each module is an ordinary `Node.js`-style module, using the `require()` function to access other modules and the `exports` global to return JavaScript values. The boot kernel smooths over the differences between `Node.js` and the browser, allowing the same plugin modules to execute in both environments.
|
|
|
|
In the browser, `core/boot.js` is packed into a template HTML file that contains the following elements in order:
|
|
|
|
* Ordinary and system tiddlers, packed as HTML `<DIV>` elements
|
|
* `core/bootprefix.js`, containing a few lines to set up the plugin environment
|
|
* JavaScript modules, packed as HTML `<SCRIPT>` blocks
|
|
* `core/boot.js`, containing the boot kernel
|
|
|
|
On the server, `core/boot.js` is executed directly. It uses the `Node.js` local file API to load plugins directly from the file system in the `core/modules` directory. The code loading is performed synchronously for brevity (and because the system is in any case inherently blocked until plugins are loaded).
|
|
|
|
The boot kernel sets up the `$tw` global variable that is used to store all the state data of the system.
|