Ticket #446 (new task)
Extensible architecture for Wikka components
| Reported by: | DarTar | Owned by: | unassigned |
|---|---|---|---|
| Priority: | high | Milestone: | blue-sky |
| Component: | architecture | Version: | 1.1.6.2 |
| Severity: | normal | Keywords: | modular plugins addons |
| Cc: |
Description (last modified by DarTar) (diff)
The current architecture allows little flexibility/configurability. After a discussion with JavaWoman on #wikka we decided to implement, as of 1.1.7, some preliminary changes that should allow more flexibility for components such as actions, handlers, formatters and language packages in forthcoming releases. This is a coordination task for the following planned changes:
1. Dedicated folders
Moving each component to its own subfolder provides several advantages, in particular the ability to add further support files (images, libraries, metadata, settings) for each component. So instead of calling an action as actions/calendar.php we will call it as actions/calendar/calendar.php. Component folders are also useful to provide drop-in support for user-contributed plugins that may come as zipped files or tarballs to extract and put in the appropriate directory, e.g.
actions/ .....myaction/ ........css/ ........img/ ........inc/ ........js/ ........lang/ ........myaction.php
As for language packages, this modification will allow to store localized definitions for default pages within specific language folders, e.g.:
lang/ .....en/ ........defaults/ ........en.inc.php
Subtasks
2. Directives
Currently, information on how to handle content associated with a specific handler is hardcoded in the core. For instance the core engine contains instructions on the different kind of HTTP headers to be sent along with handlers such as /raw, /show, /mindmap.mm etc. Instead of hardcoding these directives, we should put them in an .inc buddy file, coupled with each component. Every time a handler is called, the engine will check in this buddy file what kind of directives need to be followed.
Subtasks
- Prevent mutiple calls #634
3. Metadata
Buddy files can hold not only procedural directives, but also metadata about a component. For instance, a remote URL to check whether the installed component is up-to-date. Component metadata could then be used by plugin managers to display information about installed actions, handlers and formatters.
These changes can be implemented little by little. Our goal as of 1.1.7 should be to prepare a file structure compatible with this general plan (i.e. at least step 1).
