Dap 0.1.6 Language Quick Tour

Dap is developed to provide an easy and powerful means for complex and extensive DOM rebuilds with dinamically resolved dependencies.

Dap language is rather "functional", than "imperative". That means, dap rules do not specify imperatively for each click event: "update Node1, Node2 and another dozen of nodes; hide Node765432 and show P elements inside DIV elements, having class .NodesToShow, slowly". You needn't provide all the wirings to make the nodes interacting with each other. Instead, dap rules simply specify the node generation rule, like: "This node is built using variables A, B, X and may update variables A, X, Y, Z". And all dependencies are resolved by dap engine automatically. When any of A, or B, or X changed, the node rebuilds automatically. When the node changes any of A, X, Y, Z — all the dependent nodes are updated — automatically, too. No any additional wirings needed.

Such a "functional" way of document definition may appear pretty much different from what web-developers are used to. It might seem complicated and cumbersome when reading syntax specification, but when it comes to actual coding — it turns out to be quite easy and handy.

I'd recommend that you see the 'Hello, world' tutorial before getting into dap syntax details. That would help you keep track of what is it all about.

Rules and Phases

All dap rules consist of steps, steps consist of tokens, tokens consist of parts. Very simple:

rule ::=step{; step}
step ::=token{ token}
token::=[field][$status][:converter{,converter}][@alias][=value]

That is, steps within a rule are separated by a semicolon+space; header and tokens within a step — by a single space; multiple converters are separated by commas. All token parts are grammatically optional. Empty strings are valid names, but in many cases they are reserved and have a special meaning.

A dap-enabled node may have none, any or both of the following rules, corresponding to node life phases:

Data or Down phase: d-rule

When a dap node is populated, its content is generated using its d-rule, and according to its status status context and data context. Execution of d-rule of a node may change any particular entries of its contexts, and theese changes will be observable by the nodes's descendants and after-siblings.
User or Up phase: u-rule

When a dap node is activated (usually, by a user-related event), its own u-rule and u-rules of its ancestors are executed, starting from the node and bubbling up. Changes made to status entries are automatically reflected in all dependent nodes, initiating rebuilds for the nodes who's content does depend on the changes made. Changes in data entries do not initiate updates, yet their updated values are used in rebuilds initiated by status updates.

Steps and Tokens

Each rule consists of one or more steps, wich are executed consequently on the rule run. A step consists of tokens. The first token of a step is the step's head; the rest are data tokens (or simply tokens). Data tokens define data involved in the step execution; step head specifies actions to perform on that data.

Zero or more data tokens may participate in execution of each step. A token is a structure, that defines a datapiece passed to a mapper. Data tokens are not just identifiers, but execution units wich provide some simple data manipulations, such as data binding, assignments and conversions. Token may reference a data entry, a status entry, or specify a literal value. Token also specifies conversion chain for the datapiece, and an alias, under wich the datapiece is fed to the mapper.

Each token may contain:

data entry reference
status reference
conversion chain
alias
literal value

Token parts are separated by their respective prefixes: $ (dollar sign) — for status entry reference, : (colon) — for conversion chain, @ (at sign) — for alias, = (equal sign) — for value. Data entry reference, if present, is not prefixed, but is placed as first part of a token. All token parts are optional, but their order is mandatory. Full token looks like:


						data$status:converter1,converterN@alias=value

and its meaning is:

read data entry from the node's data context, or take literal value if data entry is not specified or not present in the data context.
store it as a status entry in the node's status context
sequentially apply all the converters,
provide the executed token with an alias.

Omitting any token parts modifies token behavior in a straightforward manner:

if no converts specified, datapiece is fed as is
if neither data entry nor literal value specified, the status entry's own value is taken
if no status entry specified, none is changed
if no alias provided, the result is named after the entry (or left anonymous, if none of those are specified).

A shortened form is allowed, in which status entry name is omitted, while the $ prefix is present, like: entry$. This form is equivalent to entry$entry (read value from a particular data entry and store it in a status entry with the same name). This shorthand is very common in dap, it helps keeping the code cleaner and encourages reasonable entry naming.

Setting and getting status entries

As can be seen from the token structure description above, a status variable's value can be set (by specifying a literal value or a source data entry) and can be read (by omitting both literal value and data entry reference).

Setting a status entry has different semantics for up and down phases:

at the down-phase, a new status entry is introduced in the node's scope of status context; should a one with the same name already exist in outer scopes, it is hid from the current scope
at the up-phase, the referenced entry is first searched in the context, then, if not found, created new.

Reading a status entry always assumes that it is present in the node's status context (has been already introduced — in the node's ancestors' d-rules, or in the current rule earlier), otherwise rule fails.

Converters

Converters allow to... yes, convert, the result of token execution. Converters only change the result, not the source of the value. This changed value is fed to the mapper, but not written back to the entry it was obtained from.

Dap core provides the following converters:

esc, usc
escape/unescape(string)
+, -
absolute/negate value(number)
?, !
test if value(any type) present/missing
+?, -?, 0?
test if value(number) is positive/negative/zero
#get, #cfg, #dat, #lib
converters of this group "convert" the value(url) into data received from that url
csv
"Comma-separated values". Converts x1,x2,x3-like string into a single-column rowset.
nvp
"Name-value pairs". Converts x1:y1;xN:yN-like string into a multi-column (x,y) rowset.
Rows need not be "pairs", any number of colon-separated columns is allowed.

Custom converters may be defined in extension libraries.

Step head

Step head is the first token of a step. Step head itself doesn't fetch datapieces; it defines what to do with the rest of the token list. It has the same structure as an ordinary token, except that its data part specifies a dap mapper, and its value part specifies a token list flattener.

Flatteners

A flattener may be applied to the token list to convert the whole list into a single datum, wich is fed to the mapper instead of individual tokens of the step. Alias for the flattened datum is specified by the head's alias part.

The most basic dap core flatteners are:

concat
Concatenates values of all tokens into a single string
space
Concatenates values by a single space
url
Builds an URLEncoded query string. Anonymous tokens are appended unencoded.
?, !
ANY(returns first non-empty value from the token list) / LACK (returns true if at least one token is false/empty)

In conjunction with ! converter, these flatteners become NONE / ALL respectively
eq, asc, dsc
Check respectively for: equality, monotonous ascend or monotonous descend of the token list
Equality check may be performed upon any data, whereas ascend and descend checks — only upon numbers.
Examples

!=concat =abra @foo=cada @bar=bra
abracadabra

!=space =abra @foo=cada @bar=bra
abra cada bra

!=url =abra @foo=cada @bar=bra =hmaputra
abra&foo=cada&bar=brahmaputra

!=? @empty= @foo=cada @bar=bra
cada

?=eq =abra @foo=cad @bar=abra
false

?=eq =abra @bar=abra
true

?=asc =-1 =7 =12 =13
true

?=asc =-1 =7 =15 =13
false

?=dsc =-1 =-7 =-12 =-13
true

Custom flatteners can be defined in external libraries.

Mappers

Mappers to dap are what functions to javascript are. They take "arguments" and perform "actions". Dap mappers are unary — they deal with only one token at a time. Multiple tokens in a step are executed as a "for each token" sequence.

Since all mappers are unary, the following signature may be used for their description:

mapper @alias=value

Each token comes to a mapper as an @alias=value datapiece. Alias is specified by token's @alias part (or an entry name, or anonymous), and value is the result of token execution; it is also subject to conversions, if specified. If the token's alias is empty (like in =value, or data@, or data$status@:convert=value, etc.), the token is said anonymous. In some mappers, anonymous tokens have specialized meaning over named ones.