This style guide provides comprehensive standards for writing clean, maintainable, and consistent MOX code for Moxie.Build. Code examples on this page are for illustrative purposes and are only intended to demonstrate style conventions.
An Include Procedure cannot be executed directly, the contents of its source code can only be Included into other Procedures using the Include command.
A Public Method may be called from any other Procedure, by the Default plug-in as part of the CMS.
A Remote Method may be called by any other Moxie system. It can be used to divide up a large system among a number of backend servers, or as a public API for 3rd parties. In order to call a Remote Method from MOX, the Remote statement is used.
A Message Handler is only ever called by the Database on a Database Event. These Event Messages allow a Developer to intercept operations taking place on a per-record level and implement Event based business logic.
A PaaS Method may be called by any other Moxie system. In order to call a PaaS Method from MOX, the PaaS statement is used.
Record Reports are presented to the users of the Default Admin interface and are also intended to be made available in a dynamic way to users of a customized front end. As a Report, the Procedure is expected to produce output to be displayed to the user.
Table Reports are presented to the users of the Default Admin interface and are also intended to be made available in a dynamic way to users of a customized front end. As a Report, the Procedure is expected to produce output to be displayed to the user.
The MOX coding and programming language pays heritage to BASIC, but has been crafted for the specific type of work and environment that is demanded of Moxie.Build.
Record Actions are presented to the users of the Default Admin interface and are also intended to be made available in a dynamic way to users of a customized front end. As an Action, the Procedure is expected to perform some sort of task, such as an automated set of updates to the Database Record.
ExportSchema and ImportSchema are BuiltIn procedures that are available for use with source control systems.
Developing in Moxie.Build on localhost give you the advantage of working with the template files natively. When working on procedures (MOX code) you need to access that through the Procedures page in the Admin area of a Moxie.Build system, if running the server on localhost or on a remote server. When running on a remote server, you can edit the template files via the Files page in the Admin area.
For small and simple procedures that are not expected to grow in complexity over time, simple routing based on URL parameter values from a [Pull] directly from the Request query is sufficient and requires less code. For complex procedures that are expected to grow and evolve over time, a larger more robust foundation for the routing should be used.
A .mox file, with MOX code in it, can be run from the command line while a Moxie.Build system is not otherwise already running.
Takes one parameter, TestCondition
The optional Moxie.http file is read on server start and controls the default HTTP headers set for all requests.
The Moxie.cfg file is read on server start and controls aspects that cannot be changed while the server is running.
Takes one parameter, Value
Takes three parameters, Url, InputQuery, OutputQuery
Takes a variable number of conditional statements to compare against a single source
Takes one parameter, SlowWritePercent
Private Method contained within a given procedure.
Takes three parameters, Url, SaaSTenant, InputQuery, OutputQuery
Takes one parameter, TableName
Has no parameters.
Takes one parameter, Source
Takes no parameters
Takes four parameters, FieldBase, Destination, Source, IfLenFld
Takes 6 parameters, Location, Mode, ActionLabel, ActionPath, Class, ActionMethod
Takes two parameters, FileName, bHasHeader
Takes two parameters, Source, Match
Takes two parameters, Source, Match
Parameter is divided into two parts, the Test and the Result if True. The test comes prior to the keyword of Then and the Result if True comes after.
Takes two parameters, Source, Match
Takes one parameter, HtmlEscapedString, and returns the Unescaped Version of this string
Takes one parameter, Source
Takes two parameters, Source, Match
Has no parameters
Has no parameters
Brief overview on the file structure and contents under Moxie. The files and folders discussed in this post are those that are essential when upgrading to the most recent version of Moxie.Build , or when troubleshooting server errors.
Accepts a space separated list of field names.
Parameter is divided into two parts, the Test and the Result if True. The test comes prior to the keyword of Then and the Result if True comes after.
Takes a variable number of conditional logical if statements
Takes one parameter, the Name of the critical section
Takes one parameter, ProcedureName
Has one parameter.
See Text Operators