Lighttouch is a framework that makes complex application development simpler. It does this through broad use of component-oriented design intended to offer programmers a well-researched alternative to starting with a blank canvas - "put your code anywhere".
Code organized this way is:
- easier to program
- unlimited in its reusability of implementations
- easier to extend with other developers' plugins
- possible to socially cross-pollenate diverse and complex applications
- possible to use as a base for visual programming environments
Without this, applications tend to:
- get walled into handling only a single use case
- grow, but at huge cost and pain while extending
- repetively make messy mistakes, like spaghetti code and code duplication
- suffer too many layers of abstraction
Below you'll learn what is ECA-Rules, but to begin let's start with a simple diagram from the Drupal Rules module, a project which greatly influenced this one.
Packages are Lighttouch's main unit of addon functionality. They leverage event-driven, rule-based programming. This basically means that packages have actions, events, and rules. Events are like hooks where additional logic can run. Rules check a conditional statement of any complexity and trigger events. When an event triggers, its actions run in weight order. Actions are the individual mechanisms of additional functionality that have a distilled purpose and can run on any associated event.
80% of this functionality builds on top of Luvent: A Simple Event Library for Lua. You could probably get away with the summary below of Lighttouch's use of its API, but it's still worth checking out. It has a great Readme. The basic difference between what Luvent does and what Lighttouch does is that while writing a Lighttouch app, you put functionality into individual files, and Lighttouch sets everything up for you.
Events are very simple. They get loaded into a global list by reading each package's events.txt file. They can be disabled in a disabled_events.txt file. (aside: Potential improvements include a simpler interface and ordering execution by weight.)
Rules are basically an IF statement with some metadata. If the configured conditions, specified in the body of a rule as Lua code are TRUE, then the specified events will trigger and the objects specified in the input parameters will get passed to the attached actions.
Actions are individual, lazy loaded functions that can run where they are needed. You simply code what you want to do, and leave the parts about when it will run and in what order to the other logic connected through the yaml header. Actions should not have conditions in them.
See Lighttouch Package:
- Lighttouch Web Logging: (for web automation) log every incoming request, outgoing response, outgoing request, and incoming response (server and client logging out of the box.. makes debugging web applications much easier) to log directory (log entries are content, btw)
- Lighttouch JSON Interface: REST API built on content module
- Lighttouch HTTP Interface: form-driven content entry mechanism, username:password protected (autogenerated at each initialization)
- Lighttouch Crypto Tools: setup a profile with cryptographic signing keys for yourself and friends to verify incoming responses and requests, and sign outgoing requests and responses + and more
Lighttouch relies on ContentDB for content management and some other libraries found in the Lunar Transit account.
To install Lightouch, first install Torchbear, then run mp install lighttouch.
To modify any functionality in Lighttouch, clone this git repo, run mp unpack, make your changes in that directory, and work from the git repo in place.