The sheets and their programs

Foreword

Reading this document assumes that you have already read and understood the 'Understanding the Structure of a Storga Document' page of the manual.

If you have trouble following the text that follows, you can also consult the following subpage, which describes in detail the sequence of operations to be carried out to build the form for this document:

▸ Click-by-click description of how to build the form described below

An example of a file

Let's take as an example a simplified version of an invoice:

The 'Organize' mode with detailed display allows us to understand how this sheet is constructed:

We therefore have a form block, which contains two elements which are a table block and a program block.
The form contains three simple fields, which are 'date', 'customer' and 'total',
as well as an 'article' sub table with 4 columns: 'code' 'quantity' 'unit_price' and 'price'.
The '' and '-' buttons are used to add or remove rows in the sub table.

Finally, here is the listing of the program for this example sheet:

each prix
  prix := quantite*prix_unitaire
total := sum prix

which reads as follows:
For each 'item' table row (more exactly, the table that contains the 'price' column)
we calculate the field 'price' as being the product of the field 'quantity' by the field 'prix_unitaire'
Then we calculate the 'total' field as the sum of the different 'price' fields

The minimum elements of a file

Give a type to the form

In terms of properties, it is essential to fill in at least one row of the table of types of forms. Indeed, it is this which makes it possible to identify the nature of what the file contains. In our example, we chose 'invoice'.
Associating a type with a form allows at the level of a report to specify that we want all the forms of type 'invoice' and to find in this form only invoices, and not contact files for example .

Being able to associate multiple types with a form is a very important property. For example, we can choose to build a form that is both an invoice and an accounting entry, in which we will find all the fields that we expect to find in an invoice, and all those that we 'expects to be found in an accounting entry.

Identify fields

Then, each form input field must have a unique 'Variable name' field.
For example, here are the properties of the date field of our example form:

Notice that the name of the input fields is visible, displayed in light gray, in the view in organize mode of the form.

Finally, for the input fields that are part of a sub table, we must fill in three pieces of information. The screenshot below corresponds to the properties of the 'Price' field on the first line:

The 'Table name' field must be identical for all the edit controls forming part of the sub table.
The 'Group of variables' field must be identical for all the sisie fields of the same row of the sub-table.
The 'Variable name' control must be identical for all the edit controls of the same column of the sub table.

This means in particular that 'Variable name' is used as well to define the identifier of a simple edit control of the form as of a column of a sub table of the form.

In our example, the 'total' field is indeed a simple input field of the form, like the 'date' and 'customer' fields even if we have chosen for reasons of graphic aesthetics to put it in the table which is used to store the 'article' sub-table, so it must keep 'Table name' and 'Group of variables' empty.

Buttons

The predefined function buttons

In forms, two types of buttons are mainly used.
Those like in this example who perform an elementary operation, namely add or remove a row in the sub table.
Here is what appears if we ask for the properties of one of the buttons:

The button's function is defined in the 'Action' field.

Calculation buttons

For comparison, here is what we would have in terms of the properties of a button used to perform calculations:

The 'Action' field indicates I am a calculation button, and the 'Button name' field indicates my action code is 'b2'

To such a calculation button will correspond in the program of the form a sequence of the type:

if button_name="b2"
  ...

Printed version of a sheet

For the printed version (or PDF export) of a sheet, we often want a more precise layout.
Storga allows you to build a template in the form of a document in ISO 26300 format (often called Open Document Format).

Concretely, the extension of the file to be produced is .odt
You can either use LibreOffice writer or a version of Microsoft Office that supports ODT format.

Once you have created the file, select the properties of the form (see screenshot above), then use the 'Upload' button next to the 'Layout file' field.

Here is an example of a page that could be used for the simplified invoice sheets which serve as an example:

Note that the names of the fields are simply provided in braces.

Also notice the syntax for the fields of the sub table in the form {table_name/1 or 2/name_of_the_variable}. Moreover, in the sub-table, there must be exactly two lines, which will necessarily be numbered '1' and '2', whatever the value of the parameter 'Group of variables' of the real fields of the file.
This convention allows Storga to automatically add or remove lines.

Then, to test your file, all you have to do is select 'Open' or 'Print' in its context menu.

Finally, note that if the substitution of one of a field does not work, it is usually because the name is incorrect, or because you have changed the typographic attributes in the middle of the name, which is more difficult to diagnose. because it does not show. The easiest way is to erase the name and the two braces that surround the problematic field, and to type them again.

Automatic update of records

This functionality is described at the end of the document 'Models'

The programs

Programs in Storga forms correspond to both calculation formulas in a spreadsheet, as well as macros.
There is a whole programming language described in the 'Formulas and Storga programs' part of the manual.

In this page, we are not going to explain how the programming language works, but simply list what it allows to do, in outline:

On the other hand, Storga imposes a restriction, not for technical reasons, but to promote the fact that Storga deployments remain easy to maintain:

This constraint should be compared with object programming, or an external function cannot directly change a field of an object.

In the end, can Storga replace a relational database?
In short, the answer is: yes, when you think of your organization in terms of optimizing activities and not IT development.