Creating a Wiki with Wicked and Filter

wicked depends on the 'filter' product (see REQUIREMENTS.txt). The filter product allows developers to specify 'filters' for AT schema fields; these will be applied to those fields when the accessor is called. In wicked's case, the text of a field is parsed for wicked links, and any that are found are either resolved or turned into a new "add" link. For now, a field must inherit from the FilterField class for filtering to work, but we hope to be able to allow filters to be applied without the use of this mix-in in the future.

wicked ships w/ two example content types. The first of these is IronicWiki, so called because it ironically mimics older-style wiki content by providing a dedicated content type for wiki-aware behaviour. More interesting, however, is WickedDoc, the second example type; WickedDoc depends on ATContentTypes and will only be installed if you have ATCT installed. WickedDoc is simply a subclass of ATDocument, except that the primary 'text' field has been made wiki-aware. This is a good demonstration of how easy it is to make ANY field of any content type wiki-aware with the filtering approach.

The wicked linking mechanism is very simple. All wicked linking is explicit; links are specified by enclosing content text in ((double parentheses)). A wicked link will resolve under one of the following conditions: 1. a matching id within the same folder 2. a matching title within the same folder 3. a matching id somewhere else in the site 4. a matching title somewhere else in the site

In cases where there are duplicate matches (possible w/ 2, 3, or 4), then the earliest created piece of content will be considered to match. Id matches are case sensitive, title matches are not.

Note that wicked links will match against ANY content that is in your Plone site, NOT just other content of the same type. Also note that wicked linking mechanism works equally well when used for plain text, structured text, or HTML content, and whether using a regular browser text box, a browser-based WYSIWYG editor such as Kupu or Epoz, or an external editor.

When a wicked link does not resolve via any of the mechanisms specified above, it will generate an add link in the form of a plus sign ("+") after the wicked link text. Clicking on this link will create a new piece of content of the same type as the document being viewed, in the same folder.

Advanced:: ----------

Added types:

By default, wicked add links will create content of the same type as the content within which the wicked link resides. Hooks have been provided, however, to allow for creation of other content types; intrepid developers may be able to make use of this for use cases that require wicked links to generate different content types.

Scope:

If a wicked link is found to not resolve in the current folder, then the default behaviour is for the entire site to be searched for a possible match. It is possible, however, to specify a 'scope' attribute on the field. This field attribute should be a string that specifies an attribute (or method) on instances of the class. This attribute or method should specify a valid 'path' index query expression. If the 'scope' is specified, this will limit the secondary link resolution scope to that determined by the path query expression. There are currently no example types which make use of this feature, but the unit tests in the 'test_wickedscope.py' file monkeypatch this behaviour into the IronicWiki type and then test the scoping mechanism.