Cypht has a modular design. Instead of an application with a plugin API, Cypht is an application comprised entirely of plugins, or as we call them, "module sets". There is only one required set, the "core" modules. The components of any module set can be added to, or even replaced, by site specific modules. All the functionality of Cypht is broken out into module sets, and each set is built from small pieces that are also easy to override. The module system is powerful, but also a bit complex. First let's take a look at the module sets that come with Cypht:

Module sets are setup in the hm3.ini file. With the exception of the core module, they can all be enabled or disabled independently (though module sets can rely on each other, like the nux module). When the site build process is run, module assignments are calculated and saved in the configuration file (so they don't need to be re-calculated at run-time). There is also a debug mode in which modules are activated dynamically (for the most part) to make development easier.

File Structure

Module set names in the ini file match the directory the module code is in under modules/. Files in a module have pre-defined names. Any other required code should be included from one of these files.

A module set can also include an assets sub-directory. Anything in that directory will be made availble in the browser. An example of this is the HTML WSIWYG editor for the smtp module set. In debug mode the module site.css and site.js files are included directly if they exist. In production mode combined and optionally minified versions are used consisting of a single js file and a single CSS file generated by the build process. Minifying programs can be specified in the hm3.ini file.

Input and Output

There are two kinds of modules: Input processing modules called "handler modules", and output formatting modules called "output modules". Modules can pass data to each other, and output modules have access to all the data input modules create. By default, module output is immutable and can't be stepped on by other modules. Data can be marked writable and an "appendable" data type is also supported. The typical job of a handler module is to analyze user input and do some work based on it, which it then sends to the output modules. The typical job of an output module is to take the results of an input module and format it for the browser.

Hello World

For more information, check out the "hello world" module set. It illustrates how modules work and has loads of comments that explain what is going on: