APL

Application Presentation Language (APL) Functional Spec

Overview

The application presentation language describes the user interface presented to a user creating a new application from a template or editing an existing application. It describes what questions to ask, how the questions are presented (a free form field vs. a pull-down list of options for example), and the names of the variables used to store the values the user inputs. Note that this spec only covers the APL and does not cover the actual rendering of the application template presentation

Language Description

The application template language describes the user interface presented to a user making a new application, or editing an existing application. It describes what question to ask, how the questions are presented (a free form field vs a pulldown list of options for example), and the names of the variables used to store the values the user inputs. It consists of a set of primitive form elements (string, number, choice, object), a set of grouping and organization constructs (section, list), methods for hiding or displaying portions of the form based on the values of other portions (optional), and a method to associate human readable text with various form elements (text).

Layout Elements


Functional Elements


The Text String Table Element

Many of the APL elements above have associated text string that go along with them. Section elements have labels that go along with them. The various input elements have question strings that go along with them. These strings are defined in the text table.
The text table goes at the bottom or the presentation section, and it should contain an entry for each APL element used above it. Elements are specified by their location. Objects inside of sections are specified with the section name followed by a period followed by the element name. Elements inside a row or table element are specified with the row or table name followed by a period followed by the element name.
section foo {
    string bar
    table two_columns {
        string column_1
        string column_2
    }
}

text
{
    foo "This is the label for the FOO section."
    foo.bar "What value do you want to set for BAR?"
    foo.two_columns "What values do you want for these two columns?"
    foo.two_columns.column_1 "Column One"
    foo.two_columns.column_2 "Column Two"
}

Localization and The Text String Table Element

Alternative text sections can be defined for other languages. The appropriate section will be chosen based on the browser language setting. The alternate language text sections are specified with the use of the language string following the label ‘text’.
section foo {
    string bar
}

text
{
  foo.bar “default text”
}

text "de_AT" {
    foo.bar "text for Austrian locale"
}

text "zh_CN" {
    foo.bar "text for Chinese simplified 用统一码 (Unicode) 走遍世界"
}

The entry to specify the additional language strings should be formatted in the following manner:
"<ISO 639-1 Language Code>_<ISO 3166 Country Code>"
The language codes are expected to be in lower case and the country codes are expected to be in Upper case.

Dynamic Data Binding with TCL Expressions

Most value types allow using a TCL expression to dynamically generate the default value or list of available choices at runtime rather than when the template is created. These TCL expressions can be used to retrieve information from MCPD and then process the data as needed. Once the TCL script has been executed, the returned data is processed to separated it into discrete items separated by newlines (‘n’). Each of the items are then split by tabs (‘t’) into “display” and “value” pieces which represents what the user sees, and what is saved to MCPD respectively. If no tab exists, then the “display” is the same as the “value”. For example, if a TCL expression for a choice element returns: “disp1t val1n disp2t val2”, then the list of items presented to the user would be “disp1”, “disp2”.
This example creates a choice that presents the list of the names of ltm pools. Note that tmsh commands are used to retrieve the data.
section foo {
    choice pools
        tcl {
            set objs [tmsh::get_config ltm pool]
            foreach obj $objs {
                append results [tmsh::get_name $obj]
                append results "\n"
            }
            return $results
        }
}

Validators

Validators can be used on certain value types to give a hint to the UI about what should be allowed. MCP always has the final say on what is allowed, but if the validator hint is given to TMUI, it can present a more useful error message right at the location of the error. The names of the validators are mapped to existing validation classes within the internals of TMUI. The APL validator name is case-insensitive.
APL Validator Accepts
FQDN Domain Name (RFC 1034)
IpOrFqdn ipv4, ipv6 or domain name (explicitly disallow “*”)
IpAddress “*”, ipv4, or ipv6
NonNegativeNumber Integer >= 0
Number Any Integer
PortNumber “*” or int value 0-65535 (inclusive)

Example of a validator in use to restrict the value of a text box to be a valid port number:
string port default "*" validator "portnumber"

Usage & Limitations

  • Forward definition order
  • No nested sections
  • No nested tables
  • No TCL insertion inside optionals
  • Optionals inside tables must depend on elements outside the table

The BIG-IP API Reference documentation contains community-contributed content. F5 does not monitor or control community code contributions. We make no guarantees or warranties regarding the available code, and it may contain errors, defects, bugs, inaccuracies, or security vulnerabilities. Your access to and use of any code available in the BIG-IP API reference guides is solely at your own risk.