This is an attempt to analyze more closely (aka ramble about) the function of different action plugins in MoinMoin. The purpose is to improve the interface for invoking the actions, as well as make it easier to develop new actions and maintain existing ones.
Current situation
Actions are the most generic and versatile kind of plugin in MoinMoin. They are basically small web applications, using MoinMoin as a kind of framework and a source of ready components. This flexibility comes at a cost: you need a lot of code to make an action. Even if you mostly use the ready components that MoinMoin provides, you end up with a lot of boilerplate that was copy-pasted from other actions. This is bad, because:
- it's harder to write new plugins, you have to know what to copy and where,
- it's easy to make a mistake and introduce a bug,
- it's hard to fix a bug in all the places to which it was copied,
- it's easy to break compatibility when releasing a new version,
- it's difficult to accommodate the actions in themes that work differently than default ones,
- it's difficult to keep the behavior and interface of plugins consistent,
- themes have to use heuristics to decide how to handle particular actions.
Plugin categories
Looking at the plugins, one can separate them into several different categories, based on the way they behave and the purpose they fulfill:
Views
View actions show the contents of a particular page, or some meta-information about that page. There is a standardized user interface around the displayed content, provided by the configured theme. There might be also additional links to actions not available in other views. What is displayed depends on the action, but also on the mimetype of the page, parameters in the query part of the url or user preferences and wiki configuration. Examples of such actions include: view, edit, gui edit, info, diff, chart, spellcheck, local site map, like pages, preview.
Operations
Operations are actions that are supposed to do something with a particular page. They display some sort of a dialog, usually containing a form with several fields and a confirmation button -- but there might be also some "single click" operations without any additional dialogs. Apart from the dialog, they usually display the "default" view of them page. They are not meant to provide information, but rather to perform some one-time change with the page, and return to its main view. Examples of operation actions include: bookmark, backup, despam, delete page, rename page, refresh, copy page, quicklink, subscribe, save, sync pages.
Exports
Export actions are a lot like view actions, in the sense that they provide the information from the page in a specific format, except that they don't have a standardized user interface, but instead display the information raw, suitable for downloading and saving as a file, or using in other ways. Those actions include: raw, package pages, rss, render as docbook, pdf action, sitemap, slideshow.
Interface
There are some actions that don't really deal with specific pages, but are part of the general user interface of the wiki itself. They usually work like the operation actions, in that they display some form or dialog, but the information they show and work they do is not connected with any one page. They are supposed to return to where they were invoked. Some of those are: user prefs, full search, title index, recoverpass, newpage, newaccount, login, logout, system info.
Composite
Some uber-plugins are in fact whole bundles of different sub-actions, each of them belonging to one of the above categories. There is usually one or more view action, that contains links to operations, exports and interface actions. Examples of such actions inclde: Attach File, arnica.
Consequences
Plugin development
Each class of the action plugins could have a different base class used for implementing it -- requiring only the minimum amount of code to be added. For example, a view plugin would only need a function that tells the parser to be used, similarly, an export plugin would specify a parser, formatter and maybe a mime type. The operation action would specify a function to display the dialog form, and a function to call when the form is submitted -- leaving all the display and redirecting issues to the base class. The composite actions could benefit from a standardized dispatcher...
The base classes could also define a number of (overridable) defaults, like whether a particular action should display the info line, or whether it should be visible on the editbar.
User interface
Cleaner menus
Links to actions with different plugins can be displayed in different parts of the page, appropriate to the behavior. For example:
- Views can be displayed using tabs, making it clear that they show different information about the same page.
- Operations can be displayed in some tool bar or icon bar, making it clear that they result in changes to the wiki.
- Interface actions can be grouped together in one place, separated from the page content and not getting in the way.
- Export actions can be moved to footer, or even only displayed in a separate "export" action.
- Composite actions have one "main" action that appears in the menu and displays all other components as needed.
Consistent behavior
Because plugins use templates in form of base classes, their behavior is consistent and usability improvements propagate to all actions, without additional work.
Consistent styling
Actions use the same CSS classes and IDs for the same functional component, making it easy to apply consistent styles. On the other hand, actions with differing behavior use different CSS classes and IDs, giving the style author more freedom in handling paticular use cases, without risking conflicts.
TextCha
- For some actions a textcha is mandatory (if enabled). The textcha dialog needs to be assigned to the action if both types of actions grouped together.