- WebMCP uses the Moonbridge Network Server to handle HTTP requests. The Moonbridge Network Server listens to a TCP port and passes control to WebMCP by calling request.handler(...) for each request. However, before any request is processed, WebMCP will initialize the environment. This initialization includes tasks such as + A WebMCP application may consist of several (sub-)applications. Each application sharing the same base directory also shares the database models but may provide different views and actions. The views and actions of an application are found within the "app/application_name/" directory, relative to the application base path. When starting WebMCP, the application's base path as well as the desired application name must be provided. +
++ In addition to selection of an application, a config file must be chosen when starting the application. This enables to run an application in different contexts, e.g. you may have one configuration file for development purposes and one for productive use. Configuration files are found in the "config/" directory, relative to the application base path. +
++ WebMCP uses the Moonbridge Network Server to handle HTTP requests. The Moonbridge Network Server listens to a TCP port and passes control to WebMCP (by invoking bin/mcp.lua in the framework's base directory), eventually resulting in a call of request.handler(...) for each request. However, before any request is processed, WebMCP will initialize the environment. This initialization includes tasks such as
- Filters and initializers are created by adding files in the application's directory structure. The filename determines the execution order of otherwise equally ranked initializers and/or filters. It is a common idiom to start the filename of a filter or initializer with a two digit number to be easily able to change the execution order when desired. Filters and initializers are executed both before and after a request. Each file must contain an execute.inner() command. The part before that command is executed before the request, and the part after that command is executed after the request. + Filters and initializers are created by adding files in the application's directory structure. The filename determines the execution order (lexicographical order). It is a common idiom to start the filename of a filter or initializer with a two digit number to be easily able to change the execution order when desired. Filters and initializers are wrapping requests, i.e. part of them is executed before and part after the remaining request handling. +
++ When an initializer or filter calls execute.inner(), execution of the initializer or filter is suspended and the remaining initializers and/or filters or the requested view or action are executed. Afterwards, the interrupted filters and initializers are resumed in reverse order (from where they called execute.inner()). Most often, execute.inner() is the last line in an initializer or filter, resulting in all code to be executed prior to request handling (and nothing to be executed afterwards).
The Moonbridge server creates forks (i.e. clones) of the application server process (i.e. the whole Lua engine including all libraries and variables) in order to handle concurrent requests. Certain initializations may be performed before forking, other initializations must be performed after forking. For this purpose, WebMCP allows an application to provide so-called "pre-fork" and "post-fork" initializers. The application's configuration files as well as its pre-fork initializers are executed before forking. The application's post-fork initializers are executed after forking. In particular, any libraries that open file or network handles during initialization must not be loaded before the server process is forked. Opening database connections must be performed after forking as well. WebMCP follows the following execution order (directory structure is explained further down):