If the applications require access to SQL data from Javascript, which are not directly related in the form data or are obtained dynamically in the user input, it is necessary to make an asynchronous request to the server.

1 Direct query service

The service srv_jqry (which allows queries SQL and programs XSQL-Scripts from javascript code) has been disabled for reasons of security. Consequently, the javascript functions getQueryValue and getQueryValues are obsolete and instead the new functions executeAsyncQueryValue and executeQueryValue. It is possible to maintain compatibility and use this service during the migration phase by activating the following flag when starting the java server:

Copy
-Ddeister.webstudio.core.servlet.app_jrep_jqry.enable=true

To do this, in the boot shell start.sh you have to uncomment the variable JAVA_AXIONAL_FLAGS.

Copy
JAVA_AXIONAL_FLAGS="-Ddeister.webstudio.core.servlet.app_jrep_jqry.enable=true"

In the new implementation, detailed in the following section, by means of the functions executeAsyncQueryValue and executeQueryValue queries SQL and programs are invoked XSQL-Scripts that have been previously cataloged in the dictionary database (in the corresponding wic) by the programmer.

2 SQL cataloged in the object

The SQL Cataloged are queries SQL and programs XSQL-Script that are cataloged in the dictionary database (in the wic corresponding) by the programmer. These queries and programs are invoked from javascript code through the new functions:

  • executeQueryValue
  • executeAsyncQueryValue
This system replaces the old functions:
  • getQueryValue
  • getQueryValues
  • JSQL_MakeXSQLScriptCall

2.1 Parameterization

The programmer has to catalog the code of the queries in a maintenance that depends on the SQL Object. Each SQL Object has its own queries so it is not a central repository.


Consultas (sentencias SELECT o programas XSQL-Script) que serán invocados desde el código javascript del formulario mediante las funciones executeQueryMap, executeQueryValue y executeQueryValues para obtener valores de la base de datos y ser tratados desde el programa.
wic_jrep_form_query
Label Description
Object Object code
Code Query identification code
SQL Statemen t SQL statement to execute

Created by The user who has created the record

  • Default: USER
Date created Date of registering

  • Default: CURRENT
Modified by The last user who has updated the record

  • Default: USER
Date updated Updated date

  • Default: CURRENT

2.2 Execution from the client side

The functions executeQueryMap, executeQueryValue and executeQueryValues execute a SQL statement previously defined in the current object. The parameters are always received as Javascript objects and the result of the sentience can return a single record.

The functions executeAsyncQueryMap, executeAsyncQueryValue and executeAsyncQueryValues, unlike the functions mentioned above, connect to the server asynchronously . Consequently, the function ends before receiving the response from the server; for this reason, the function does not return the obtained result, but it must be collected through the success function passed as a parameter.

  • executeQueryMap/executeAsyncQueryMap
  • executeQueryValue/executeAsyncQueryValue
  • executeQueryValues/executeAsyncQueryValues

3 Global variables

TO DO

This section is incomplete and will be concluded as soon as possible.

3.1 Global definitions


Menu path:
Applications / Objects (v1) / Form definition / Variables

Introducción

Esta opción se basa en una herramienta dirigida a localizar todas aquellas entidades (objetos, botones, autorizaciones, canales, transactions manager, etc.) en las que se utilice una sentencia SQL, ya sea en un campo de tipo lvarchar o clob.

La utilidad de la herramienta consiste, sobre todo, en localizar nombres de tablas, procedures, campos, etc., que se usan en las sentencias SQL en los distintos puntos de la base de datos. Incluso realiza la búsqueda en las funciones javascript que pueda tener el formulario o los eventos de los campos asociados a un formulario

La cadena o texto a buscar no debe contener metacaracteres, sino que se habrá de informar la cadena tal cual.

El metcaracter ! permite negar la búsqueda, de forma que muestra todas las entidades que no contienen la cadena de texto indicada

La utilidad permite, a parte de buscar cadenas de texto, permite también realizar búsquedas con expresiones regulares. La sintaxis usada en las expresiones regulares es la definida en la classe Pattern de Java. Se permite hacer búsquedas con expresiones regulares línia a línia o búsquedas en el total del campo.

Invocar desde línia de comando

También existe la posibilidad de ejecutar esta utilidad desde línea de comando, de forma que presentará el resultado de la búsqueda en la propia ventana de comando. La sintaxis a utilizar para su ejecución sería:

bin\ws-dbscript -code clob_find -args "p_search_table_name=*,p_text=icon_nxt_asient,p_exptype=0" -dbms base_de_datos -user codigo_usuario
El ejemplo anterior muestra cómo buscar los sitios (objetos, botones, SqlTables, etc.) en que se usa la procedure icon_nxt_asient.

Buscar una cadena de texto

Buscar en todos los sítios en que se aparece la cadena de texto UNIQUE Se indicaá * en las tablas que buscar, UNIQUE en el campo expresión y No en el campo Expresión regular.

Ejemplo con expresiones regulares

En este ejemplo se mostrará cómo buscar dentro de la definición de las tablas, aquellas que no tienen definida una primary key. Se buscará en la tabla wic_table_object, la cadena de texto ![\s\S]*.*primary.*[\s\S]* y se indicará Expresión regular Si.
wic_jrep_form_import_sqlhead
Label Description
Code Form global code for variables
Description Description of form global variables
Created by The user who has created the record

  • Default: USER
Date created Date of registering

  • Default: CURRENT
Modified by The last user who has updated the record

  • Default: USER
Date updated Date of the last update

  • Default: CURRENT

Introducción

Esta opción se basa en una herramienta dirigida a localizar todas aquellas entidades (objetos, botones, autorizaciones, canales, transactions manager, etc.) en las que se utilice una sentencia SQL, ya sea en un campo de tipo lvarchar o clob.

La utilidad de la herramienta consiste, sobre todo, en localizar nombres de tablas, procedures, campos, etc., que se usan en las sentencias SQL en los distintos puntos de la base de datos. Incluso realiza la búsqueda en las funciones javascript que pueda tener el formulario o los eventos de los campos asociados a un formulario

La cadena o texto a buscar no debe contener metacaracteres, sino que se habrá de informar la cadena tal cual.

El metcaracter ! permite negar la búsqueda, de forma que muestra todas las entidades que no contienen la cadena de texto indicada

La utilidad permite, a parte de buscar cadenas de texto, permite también realizar búsquedas con expresiones regulares. La sintaxis usada en las expresiones regulares es la definida en la classe Pattern de Java. Se permite hacer búsquedas con expresiones regulares línia a línia o búsquedas en el total del campo.

Invocar desde línia de comando

También existe la posibilidad de ejecutar esta utilidad desde línea de comando, de forma que presentará el resultado de la búsqueda en la propia ventana de comando. La sintaxis a utilizar para su ejecución sería:

bin\ws-dbscript -code clob_find -args "p_search_table_name=*,p_text=icon_nxt_asient,p_exptype=0" -dbms base_de_datos -user codigo_usuario
El ejemplo anterior muestra cómo buscar los sitios (objetos, botones, SqlTables, etc.) en que se usa la procedure icon_nxt_asient.

Buscar una cadena de texto

Buscar en todos los sítios en que se aparece la cadena de texto UNIQUE Se indicaá * en las tablas que buscar, UNIQUE en el campo expresión y No en el campo Expresión regular.

Ejemplo con expresiones regulares

En este ejemplo se mostrará cómo buscar dentro de la definición de las tablas, aquellas que no tienen definida una primary key. Se buscará en la tabla wic_table_object, la cadena de texto ![\s\S]*.*primary.*[\s\S]* y se indicará Expresión regular Si.
wic_jrep_form_import_sqlitem
Label Description
Code Form global code for variables
Name Variable name
sqli_srow
sqli_cached
SQL SQL statment

  • Format: SQLCOND_EXPR
Created by The user who has created the record

  • Default: USER
Date created Date of registering

  • Default: CURRENT
Modified by The last user who has updated the record

  • Default: USER
Date updated Date of the last update

  • Default: CURRENT

3.2 Global assignments


wic_jrep_form_data
Label Description
Code Object code

  • Default: THIS
Ignore parent selection Ignore parent selection

  • Default: 1
  • Values:
    • 1: Yes.
    • 0: No.
Ignore parent security Ignore parent security

  • Default: 1
  • Values:
    • 1: Yes.
    • 0: No.
Insert requires reset Insert requires restarting

  • Default: 0
  • Values:
    • 1: Yes.
    • 0: No.
Disable singlerow selection Disable singlerow selection

  • Default: 0
  • Values:
    • 1: Yes.
    • 0: No.
Hide head buttons Indicates if the header buttons are hidden when displaying of this form

  • Default: 0
  • Values:
    • 1: Yes.
    • 0: No.
# rows parent document Number of rows to show from parent document

  • Default: 1
  • Values:
    • 0: 0.
    • 1: 1.
    • 2: 2.
    • 3: 3.
    • 4: 4.
Form variables Form variables
Import JS Code Import javascript to the form
Input fields syle Style used for input fields

  • Default: 1
  • Values:
    • 0: Traditional.
    • 1: Material.
Input tab orientation Input of boxes orientation on tabutation

  • Default: 0
  • Values:
    • 0: Horizontal.
    • 1: Vertical.
Form design The option 'Table design' determines the algorithm for assigning the width of the columns of the form. To do this there are two options:
  • Fluid: the width of the columns adapts to the contents of the boxes.
  • Fixed: the width of the columns adapts to the size of the window and it is assigned the same size for all of them.


  • Default: 0
  • Values:
    • 0: Fit to content.
    • 1: Fit to screen.
    • 2: Flow layout.
Print inline The form consists of tabs and boxes that are issued on the distribution established in its programming.

By this argument indicates that both the tabs and boxes are issued without regard to this distribution, Items are self-adjusted the width of the page:
  • tabs : they are issued in line (horizontally), each below the previous, scheduling order following the (left to right and top to bottom) and when it reaches the right margin of the page will begin to put in the next row.
  • boxes : each box is placed in a row, ie., no more than a box in a row, following the scheduling order (left to right and top to bottom).
    The columns follow the same behavior as the tabs. Labels and fields are grouped together in a single element, consisting of all fields between two labels. These elements are distributed in line (horizontally), each one after the previous one, following the programming order (left to right and top to bottom) and when you reach the right margin of the page it will begin to insert in the next row.

This allows the page layout to be dynamic depending on the width, so that if the width changes, the distribution also does.

It is useful because, for example, zooming the page (Ctrl + + Ctrl + - in IE7 and FireFox) avoids horizontal scrolling, since fields "move down" to lower rows.

The following picture shows an example of a form issued with this method:




  • Default: 0
  • Values:
    • 1: Yes.
    • 0: No.
Hide header Hide header

  • Default: 0
  • Values:
    • 1: Yes.
    • 0: No.
Align page number Indicates where the text "Page X of Y" is positioned. It can be on the left, right, center or you can indicate that it is not displayed.

  • Default: 0
  • Values:
    • 0: Left.
    • 1: Rigth.
    • 2: Center.
    • 3: Hide.
SQL statement (execute before print) This is useful, for example, to mark the document as printed, or if something more complex has to be done, then execute a procedure.

  • Format: SQLCOND_EXPR
SQL statement (execute after print) This is useful, for example, to mark the document as printed, or if something more complex has to be done, then execute a procedure.

  • Format: SQLCOND_EXPR
form_print_stmt_before_backup
form_print_stmt_after_backup
DIN Default page size for default

  • Values:
    • NULL: .
    • A4: A4.
    • A3: A3.
    • A5: A5.
    • A6: A5.
    • A7: A7.
    • B5: B5.
    • US_LETTER: US_LETTER.
    • US_LEGAL: US_LEGAL.
Top margin In this field you can set the desired top margin for printing the object.

If the value 0 is reported, then the system will apply the value, that for this same magnitude, the user has assigned by default in his particular parameterization.

If you want to set the value 0, you should enter a value like 0.01 to prevent the system from applying the user value.
Left margin In this field you can set the desired left margin for printing the object.

If the value 0 is reported, then the system will apply the value, for this same magnitude, that the user has assigned by default in his particular parameterization.

If you want to set the value 0, you should enter a value like 0.01 to prevent the system from applying the user value.
Right margin In this field you can set the desired right margin for printing the object.

If the value 0 is reported, then the system will apply the value, that for this same magnitude, the user has assigned by default in his particular parameterization.

If you want to set the value 0, you should enter a value like 0.01 to prevent the system from applying the user value.
Footer In this field you can set the footer of the page you want for printing the object.

If the value 0 is reported, then the system will apply the value, for this same magnitude, that the user has assigned by default in his particular parameterization.

If you want to set the value 0, you should enter a value like 0.01 to prevent the system from applying the user value.
Body functions Documented in form_js_before_commit

Document_onload() Document_onload ()

Document_onunload() Document_onunload ()

Document_before_insert() Documented in form_js_before_commit

Document_before_delete() Document_before_delete ()

Document_before_update() Documentted in form_js_before_commit

Document_before_input()

To operate in js with #field, when field is numeric is Para operar en js con #field, cuando el field es numérico es preferable to put it between parenthesis or assign this value to a javascript variable, because of #field puts the value of the field, so, it will be processed in compilation time, that not is the same than to work how this was a variable.

Example
-------
let us suppose
field1: value 9
field2: value -3

if (#field1 - #field2 > 0)
This will produce a javascript error because this sentence in javascript will be generated like this:
if (9 - -3 > 0)
This is not the same that (PUT A TABLE FOR THIS, SENTECE - COMPILATION)
SENTECE COMPILATION
if ((#field1) - (#field2) > 0) if ((0) - (-3) > 0)
Or
var field1 = #field1; var field1 = 9;
var field2 = #field2; var field2 = -3;
if (field1 - field2 > 0) if (field1 - field2 > 0)



Created by The user who has created the record

  • Default: USER
Date created Date of registering

  • Default: CURRENT
Modified by The last user who has updated the record

  • Default: USER
Date updated Date of the last update

  • Default: CURRENT

3.3 Obtaining data from the client side

The following example shows how to catalog a form variable in the object 'invoices'. Its function will be that when you erase the data of the form, automatically put the client identifier that has been defined in the variable.

To begin with, a table will be created where the data that will be shown in the object 'invoices' will be stored.

Copy
<table name='invoice_params'>
    <!-- COLUMNS -->
    <column name='customerid'   type='serial' required='y' />
        
    <!-- PRIMARY -->
    <primary name='p_invoice_params' columns='customerid' />
</table>

Then the value of the client identifier that you want to show in the object is inserted in the table, in this case it will be '10000'.

Now we define the variable of the form that is going to be used, which will be as follows:

  • Code: globals

  • Description: Global variables


Next, the SQL statement is cataloged, for that you have to go to Definition of form variables. In the section Name the table created at the beginning will be put (invoice_params) and in the SQL statement the following will be defined:

Copy
SELECT * FROM invoice_params

Once the form variable has been selected, it is necessary to go to the section Events where the sentence that will be executed will be defined, in our case, each time the form is reset. For this, in Colname, customerid will be set and the statement will be as follows:

Copy
var m_customer = getGlobalString('invoice_params','customerid');
setFieldValue('invoice.customerid',m_customer);

To obtain the data of the variables you can use:

  • getGlobalString
  • getGlobalNumber
  • getGlobalObject
  • getGlobalArray

Now in the form 'invoices' the user will be able to see the change when performing the reset.


By delete all the data from the form it can be seen how the client identifier has passed automatically from '2' to '10000'.