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.
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.
This is where a module set defines it's own modules and assigns them to request identifiers. This file must return an array of valid input and associated types in order for the module code to have access to it..
This is where the actual module code lives. If you have external libraries to include this is a good place to do so.
Optional file to include CSS for the module set.
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.
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: