The concept default value references the initial value for a column when executing an insert operation.

There were three elements, which determined the initial value for a field in a document. In order as they were applied are:

1. Default value defined in column attributes (wic_jdic_colattr.col_defval).
2. Javascript form reset event (wic_jrep_form_data.form_js_before_input), executed once when form reset was executed.
3. Javascript field reset event (wic_jrep_form_cols.evt_reset), executed for each field when form reset was executed.

The main issues of this implementation was: the use of complex Javascript code for simple operations such us dynamic default values; and code fragmentation, which increased the difficulty of implementation and maintenance, and promoted performing multiple server connections when getting default values, with the corresponding performance issues.

In order to solve the issues listed before, the new implementation for default values includes:

• Replace the definition of default value in column attributes (wic_jdic_colattr.col_defval), which only allowed one value for column, by a new table which allows more than value and includes an application expression to allow apply default values dynamically.
• Boost default value expression to allow referencing global and parent values
• Add a new event Reset for object transaction manager which might execute and script returning a map with the default values.

The following cases tries to show the typical situations for defining default values and compare how was configured using the old implementation with the one.

A common case is to set an initial value for a numeric column. For example, we want to define the default value 1 for column InvoiceLine.Quantity.

The old implementation consisted on defining the default value in the column attributes parameterization.

The new implementation is basically the same, just using the new configuration table.

It exists some system expressions that are translated into a default value for an specific column. Common cases are the use of date expressions such as TODAY or CURRENT for date columns. This example shows how to set the current date for the column Invoice.InvoiceDate.

The old implementation consisted on defining the default value in the column attributes parameterization and using the constant TODAY as default value.

Another usual situation is the need of executing some query in the server for obtaining the initial value of a column. For example, the following sample consist on increasing by two the field order of the sample InvoiceLine table.

With the old implementation this situation was achieved by using Javascript code, adding a query execution on the before_input or the reset_field event. For example:

function reset_order () {
    var m_order = executeQueryValue("GET_ORDEN", [
        getParentFieldValue("Invoice.InvoiceId")
    ]);

    setFieldValue("InvoiceLine.order", m_order + 2);
}

Referencing a global variable is another common situation. For example, it allows loading the Employee information related to the current user and apply it to a certain form without adding a join to the main cursor statement. In the following sample, we assume that we have loaded the information of Employee.EmployeeId as a global variable and it will be used as default value for the column Invoice.InvoiceEmployeeId.

This is another situation which used to be done by adding Javascript code:

function reset_InvoiceEmployeeId () {
    setFieldValue("Invoice.InvoiceEmployeeId", getGlobalString("Employee.EmployeeId"));
}

It is also useful to handle parent values to determine the initial value of a column. For example, when having a range of dates in the header of a document (Invoice.DateStart, Invoice.DateEnd) and a more specific ones at the document lines (InvoiceLine.DateStart, InvoiceLine.DateEnd), it is sometimes necessary to propose the range of dates from the header as default values for the line. it allows loading the Employee information related to the current user and apply it to a certain form without adding a join to the main cursor statement. In the following sample, we asume that we have loaded the information of Employee.EmployeeId as a global variable and it will be used as default value for the column Invoice.InvoiceEmployeeId.

This implementation was achieved in the old implementation by adding Javascript code:

function reset_DateStart () {
    setFieldValue("InvoiceLine.DateStart", getParentValue("Invoice.DateStart"));
}
function reset_DateEnd () {
    setFieldValue("InvoiceLine.DateEnd", getParentValue("Invoice.DateEnd"));
}

Sometimes, the default value depends on some application logic. For example, having various default values applicable to a column with a certain priority. In the following example, if the current user is defined as an Employee (via the Employee global variable) it will apply the corresponding Employee.EmployeeId; otherwise, it will set the default value 000000.

This implementation was achieved in the old implementation by adding Javascript code:

function reset_InvoiceEmployeeId () {
    var empId = getGlobalString("Employee.EmployeeId");
    if (empId == null || empId.length == 0)
        empId = "000000";

    setFieldValue("Invoice.InvoiceEmployeeId", empId);
}

The nullability of a column is related to the possibility of letting a field blank in a form. When this requirement is fixed it is advisable to define the physical column as required, when defining the physical dictionary. But sometimes the requirement of letting a column blank includes some application logic, so it must be defined as not required in the physical dictionary and some code must be added to express the nullability requirements.

It didn't exist any parameterization structure to configure dynamic nullability, so the only way to achieve it was by using the Javascript user function setFieldNullable, in the object Javascript programing code. The main issues of this implementation are complexity of using Javascript code and the difficulty of reuse the code in other objects or components.

In order to solve the issues mentioned before the new implementation includes a new table for defining nullability client-side configuration. This configuration will be evaluated by the system to enable/disable fields nullability in objects and components.

The following cases tries to show the typical situations for defining dynamic columns nullability, and compare how was configured using the old implementation with the one.

The most common case is when a column value is related to previous column; so, it is only valid when the preceding column has an specific value. For example, imagine that the value of Employee.City is not required, but it should be required in case that Employee.Address is set.

In the old implementation this functionality was implementing adding Javascript code.

// Ensure the nullability state when changes the Address
function after_Address () {
    setFieldNullable("Employee.City", getFieldValue("Employee.Address").length == 0);
}

// Ensure the nullability state when loads the document
function document_onload () {
    setFieldNullable("Employee.City", getFieldValue("Employee.Address").length == 0);
}

Editable configuration handles when a field representing a column is editable or not. When the editable configuration is fixed the kind of field in a form or the column used in an SQLTable its enough. But when a field editable condition is dynamic is necessary to add some application logic which handles this situation.

There were three ways for defining the field editable state in a document:

• Input field editable server condition (wic_jrep_box_formdata.col_server_input_expr).
• Input field editable client condition (wic_jrep_box_formdata.col_client_input_expr).
• Using the Javascript user function setFieldNoentry, in the object Javascript programing code.

In order to solve the issues mentioned before the new implementation of column editable configuration includes:

• Generalize server and client expression by moving the expressions from wic_jrep_box_formdata to a new table linked to a table and column instead to an object.
• Client expression will be evaluated every time the fields used in the expression changes.
• Boost expressions referencing global and parent values.

The following cases tries to show the typical situations for defining enable/disable column editable configuration, and compare how was configured using the old implementation with the one.

It allows using an SQL statement to verify configuration tables for enabling/disabling editable condition for a field. For example, if it would exist a configuration table which determines if the user is authorized to modifying prices (myconftable.canedit_price), and the editable state of InvoiceLine.UnitPrice depends on that value.

Using the old implementation this functionality was implemented by defining the proper SQL statement in the server condition for enabling field edition (wic_jrep_box_formdata.col_server_input_expr) associated to a field in form:

SELECT COUNT(*) FROM myconftable WHERE user = $USER AND canedit_price != 0

It allows using simple javascript expressions for enabling/disabling editable field status. It is often used when the editable state depends on the entry mode (Insert/Update), or when depends on other non editable columns (Recall that client expression in old implementation was not reactive, so it didn't update field status when changes the fields). For example, a column Employee.EmployeeId is only editable for insert.

Using the old implementation this functionality was implemented by defining the proper Javascript expression in the client condition for enabling field edition (wic_jrep_box_formdata.col_client_input_expr) associated to a field in form:

!isOnUpdate()

It allows using expressions for enabling/disabling editable field status, involving other columns that should refresh the editable status while changing their value in form. It is often used when a column value depends on a previous column. Recovering the situation of the nullability state, the value of Employee.City should be editable only in case that Employee.Address have some data.

Recall that client expression defined by the client condition for enabling field edition (wic_jrep_box_formdata.col_client_input_expr) associated to a field in form didn't recalculate the editable status when the columns used in the expression changes. So, this functionality had to be done adding some Javascript code to the object.

// Ensure the editable state when changes the Address
function after_Address () {
    setFieldNoentry("Employee.City", getFieldValue("Employee.Address").length == 0);
}

// Ensure the editable state when loads the document
function document_onload () {
    setFieldNoentry("Employee.City", getFieldValue("Employee.Address").length == 0);
}

Client-side validation provides better user experience by responding as quicker as possible when the user is introducing an incorrect value during data entry.

Until the current version, client-side validation was performed mainly by adding Javascript code to the object, using the user function setFieldError in the object events before_insert, before_update and after_field. As occurs in previous cases, the main issues of this implementation is the complexity of using Javascript code and the difficulty of reuse the code in other objects or components.

In order to solve the issues mentioned before the new implementation of column client-side validation consist on adding a new table for implementing a validation expression and a label which must be shown in case that the expression returns false. The expression should be evaluated on client-side every time the defined column or any column referenced in the expressions changes.

The following cases tries to show the typical situations for defining client-side field validation, and compare how was configured using the old implementation with the one.

Allows verifying the input data with a simple javascript expression and showing a warning message to the user in case of the introduced value would be wrong, just after abandoning the field in form. For example, to ensure that the column InvoiceLine.Quantity has a value different from zero.

Using the old implementation this functionality had to be implemented by adding some Javascript code to the object:

function after_Quantity () {
    if (getFieldValue("InvoiceLine.Quantity") == 0)
        setFieldError("InvoiceLine.Quantity", "Quantity should different from zero.");
}

In some cases it is better to emit different warning message in order to report the user the best warning message. For example, in case that it is not allowed the zero value for the column InvoiceLine.Quantity, and neither having negative numbers.

Using the old implementation this functionality had to be implemented by adding some Javascript code to the object:

function after_Quantity () {
    if (getFieldValue("InvoiceLine.Quantity") == 0)
        setFieldError("InvoiceLine.Quantity", "Quantity should different from zero.");
    else if (getFieldValue("InvoiceLine.Quantity") < 0)
        setFieldError("InvoiceLine.Quantity", "Quantity should be a positive number.");
}

In conclusion, the pack of structure and functionality changes for implementing the new column settings are:

• New table for defining default values.
• Boost default value expressions.
• New event Reset for object transaction manager.
• New table for defining client-side column nullability configuration.
• New table for defining column editable configuration.
• Reactive evaluation of editable client-side expressions.
• Boost column editable expressions.
• New table for defining client-side column validation.