A web page can be a self contained page of pure html stored in the web server store or just the main part loaded into a template. The page consists of a url part telling the server where to load the page from and a code part that is the html code presented the user when giving the url in the browser. As mentioned you can also supply optional settings like the template to use and the data to supply the template engine.

Page templates

The page it self uses our DataEase report format consisting of page parts, livetext and tags. These are combined with a DataTree (multiview in DataEase lingo). A DataTree can consist of 1 or more level of data and statistical data for all the levels. We will do a more extensive description of the DataTree in another document.

Page parts

A page part always start at the beginning of a line starting with a . (dot) and the name of the part.

.data A data definition that is executed before the page is rendered. See page data definition for the full description of what can be used.
.dql Indicates a section holding a dql to be called when you have a single source dql. It must always be started at the first line of the source.
.template Tells what template to use when loading this page. It is a single line part in the form .template templatename/filename
.header This indicates start of a data section of a multi level DataTree. The first will give you data form level one in the data tree. The second will give you data from the second level and so on.
.group header This is a special header for use in a DataEase DQL where you use in groups at a field in a list records. A group in a DQL makes two levels in the data tree with the group field at the first level and all other fields for the list records in the next level. What a group header does are to concatenate these two levels into one meaning that you can use the group field and all the other field as LiveText inside this page part.
.items This indicates the start of the highest level in the data tree with out regard to how many headers that is given before.
.noitems If the result of the query in the page have no data, the pagepart .noitems are used instead of the .items.
.footer The first footer is the one just above the items level, the second the one above that and so on.
.group footer As with the .group header this is a helper when using in groups in a list records in a dql. This concatenate two level to one so you no longer need to use a empty header.
.end This indicates the end of the previous page part. A page part is ended at the start of the next page part, so end is usually only added at the last footer, after a dql when no template is given or after items if no footer is used.
.page Added a page break into the code. At the moment it is just a convenient way of adding a <p style = \"page-break-after:always;\"></p> in a html document, but we will make it possible to change the added string or even make it work in none html environments if needed.

LiveText

A live text starts with [{ and ends with }]. The LiveText inserts data to the document based on specific rules defined by the page parts. The LiveText can consist of three parts, the name, the format and the filter. The format can again consist of text format and aggregation commands as used in DQLs. Filter starts with a | and format with a :.

Ex.: [{FieldName:R20 sum|replace "," "."}] meaning Get the field name FieldName from the current record data the aggregated sum version of the data, make it right formatted with 20 char size and then replace the comma with a dot. The order of the filter and format counts. If you did it the other way around the filter replace would be run before the format R20.

LiveText format

The LiveText format must be the first to be added after the :. All of these are format commands are made to accommodate a text based format. The F format can also be used to reformat an internal number format to another number format used by the page output.

Lsize Left followed by a size of the field making the template engine pad the missing letters with a space. If the field data is larger than size, the field data is truncated.
Csize Center the text in a field of the size following the C command. If the field data is larger than size, it is will fill inn as much of the field data there are room for and truncate the rest.
Rsize Right padded output. A space of the size are created in the document and if the field is smaller than the size space are added in front of the field data. If the size of the field data is larger than the size, the field is truncated.
Fformat Format add you in control of how to format the output. The form added direct after the F command is a string consisting of either 0 or 9 and delimiters. Format will try to figure out what the delimiters you use means. If you have more than one type of delimiter, the first is assigned as the triplet (thousand separator) and the second as the decimal separator.

LiveText stats/aggregates

Stats or aggregates are also added after the : as with the format. If there are no format, you can add it directly after the :, if there are a format, you have to add that first.

LiveText data context

The context for the data lookup depends on the page part the LiveText is added to. If you look at the data given to the page as a tree, each level of the tree until you reach the right most is considered .header, .group header, .footer and .group footer elements. The .items page part is the left most branch of the tree. If you have aggregates , you will usually add them to one of the .footer page parts. Each .header and .footer is run once for each level of the left most branches. A LiveText will always start to look for data in it's own level and if not found walk up the tree until it gets a match. If no match is found, a blank string is returned. In a multilevel 

There might be other page data than from the data source as well. All pages have a Name definition and if a user is logged in you will have a User context as well. These can be found using dot notation. All live text with . notation ex. [{user.first_name}], will not try to look for data by the level, but go directly to direct data retrieval.

Ex. [{page.Name}] will return the name definition form the WebServer table. This can be use full for the <title> tag in a template to give each page a unique name in the browser window.

Tags

If the page contains a template name the generated page code is then inserted into the template at the position given by the [%body%] tag,