Takes 7 parameters, FieldBase, GroupBy, GroupTotals, GrandTotals, Seperator, TotalPre, TotalPost
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.
The Moxie.cfg file is read on server start and controls aspects that cannot be changed while the server is running.
The Setup Table controls aspects that can be changed while the server is running, and is intended to contain both Moxie.Build specific values as well as application specific.
Takes one parameter, FieldName
Takes three parameters, Url, SaaSTenant, InputQuery, OutputQuery
Takes a single Field name, with an optional Not operator, followed by the conditional statement
Takes a variable number of conditional statements to compare against a single source
Takes three parameters, Url, InputQuery, OutputQuery
Takes 6 parameters, Location, Mode, ActionLabel, ActionPath, Class, ActionMethod
Takes 6 parameters, Location, Mode, ActionLabel, ActionPath, Class, ActionMethod
Takes one parameter, Source
Takes one parameter, Status
Takes two parameters, Title, Path
Takes three parameters Method, URL, Body
Takes two parameters, FieldBase, SortFieldList
Takes one parameter, Source
Takes 9 parameters, ServerName, Port, bSecure, Mode, Path, ContentType, extraHeader, body, rtnHeaders
Takes a variable number of conditional statements
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.
Has no parameters.
This is our current Privacy Policy, last updated 2016-01-12.
Prerequisites: This page assumes that you have already set up your Moxie.Build server and logged in as an admin user. This page covers some of the basics that are involved in using the Content Management aspects of the Moxie.Build system.
Has no parameters
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.
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.
Table 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 Table.
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.
Takes two parameters, TableName, RltnList
Takes two parameters, TableName, ProcList
Has no parameters.