Swank Wiki
Recently Visited

Swank v0.04.04

Swank core classes



Core system base class, providing essential base functions.

handler - entry point for requests

top_action - dispatcher for top level actions

... and a few other things which did not have a good home.


Compiles page methods into perl subs, which can be added to Swank::Classless objects.


Utility functions to implement the filter syntax of the pipe symbol. e.g.  Task-37


Reading and writing pages to whatever storage medium is wanted. 

Parsing is also done here, which may be mis-factored.  Two formats are currently defined: Version 0 is for supporting raw html files. Version 1 is a hacky pseudo-xml for use until we get time to do a standards-compliant xml format.

Storage API methods: read, write, delete, exists, getkey (for serial numbers)


This is intended mostly for example of how to roll your own local Application class, including plugins needed and initialization.  Similar examples are found in the test suite.


Mainly a simplified interface to the Search::ElasticSearch module, which is an interface to the ElasticSearch server version of the Lucene project.  Lucene is a full-text search engine which also understands fields, so it provides all the essential search and indexing functions for the wiki.  Understanding fields is critical for a structured wiki search engine.

The plugin part overrides the write and delete methods for indexing and provides a search method.

Swank::ElasticSearch::Search is the real interface to ElasticSearch, dealing with the tricky and poorly undocumented techniques of accessing Lucene.

Swank::ElasticSearch::Results encapsulates a set of search results, providing automatic retrieval of page objects.


Provides RCS versioning for wiki page files.

Overrides write and delete to do versioning.

Provides history to return version data for history action.  Overrides top_action to load old versions for revision action.


Provides the interface to whatever input/output system is used for the wiki, which might be CGI, mod_perl, or whatever.  Most of the work is delegated to a helper class.

Essential functions are provided here are: print (for output), param (for input parameters), uri, path, ext (for request data), content_type, status (for response data), redirect (for redirects), tag (for outputting arbitrary html tags). 

As defined in this file, some of these methods are just functional enough for testing.  A subclass specific to the environment should be used in real life.


Swank I/O interface for a CGI environment.  Beside providing complete implementations of the IO method stubs, it also gives access to uploads and cookies.


Security-related code goes here.

authenticate, allow_top_action, show_actions, auth_check_password, auth_set_password, auth_login, auth_logout


Session handling.  Overrides handler to load the session, and top_action to save the session.

Provides session method to return the current session object (which is a non-indexed page object).


Various methods for dealing with non-page files.  (graphics, css, etc)


Provides an Exception class for Swank.  This is based on Error::Simple (and should be refactored into a subclass of that).  The major new feature is the ability to "toss" exceptions.  These are for problems which do not need to immediately stop processing, but can be collected and displayed to the user later.  This is used extensively for data validation errors.


All date classes suck, so this is mainly to isolate the suckage and allow it to be replaced if preferred.

It adds a date method to the system, which will parse a date and return a date class object.  It accepts iso-8601, and several other common formats.  The needed capabilities are tested in t/date.t

Currently, the date class is a small subclass of Class::Date, which needed some bug fixes, and a few convenience features added.


The pages themselves have their own class system and heirarchy based on Swank::Classless


This is the base class for all pages.  It provides the default top-level actions and a few utility functions.

call: provides a way to access methods in other pages, and loads them into the system as needed.  It is most of the magic behind [ % & tags.

wrap, wrapper, and next: provide the wrapping functionality described in detail elsewhere.


This is similar in nature to Class::Classless, with a couple improvements.  It uses Algorithm::C3 to simplify the inheritance tree calculations.  It uses Sub::Name in order to avoid the hackish context variable that Class::Classless has to pass around.