Overview
Artifact ID: | 541a6518d5d6028b75fad045cfd34db49c22b040ac70576c1734944cba10ce4b |
---|---|
Page Name: | References |
Date: | 2018-07-06 19:49:48 |
Original User: | mario |
Mimetype: | text/x-markdown |
Next | 2af1f5787fad0b1fb634b0ae33b949ac9b094f94fbbf7ee52fa7022f0c90731b |
Content
References / Existing Implementations
PMD is somewhat cemented now for most of my projects. Even if you don't actually need the management features. This is just a list of existing parsers and usage schemes.
Python: streamtuner2 → pluginconf
- Comes with a full parser, and handles plugin activation with a simple configuration hashtable.
- plugin_meta() can extract from files or loaded modules, and pyz archives
The admin UI sets conf.plugins{} for activcation states as follows:
"plugins": { "bookmarks": true, "cachereset": false, "configwin": true, "continuous_record": false, "delicast": true,
Plugins are scanned for meta infos on each startup (there isn't too many), and instantiated according to config table.
Hooks/
type:
are not used much. Instead class types are used implicitly, or plugins register themselves with the main application.config:
options show up in a neat combined settings window, defaults are applied on startup / to the conf{} dict.
Powershell: Clicky
- Albeit has a full parser, only the config options are fully used.
type:
covers a few magic values (init*, inline, cli, …)- But primarily the
category:
is used for UI hookup (menu structuring). Which is one of the more basic uses for plugin meta data. - There's no plugin activation states as such, all scripts are "loaded" all the time.
- Albeit there's a basic Plugin Manager now.
Ruby: cross packaage maker
- Implements just a crude parser.
- Uses PMD partially as source for packaging info. (Wasn't intended for that, but very convenient!)
- Defines the
#pack:
specifier for relative file references. Albeit partially supports#depends:
specifiers.
PHP: [libconfig / Generic PHP Plugins][http://milki.include-once.org/genericplugins/)
- Was the original implementation. Still pretty close to the current spec.
- Only the
config:
syntax uses HTML-style rather than JSOL attributes. - Main goal here was a non-destructive
config.php
editing feature via plugin meta data.