This document describes the changes and new tables added to support the new versions in wic data dictionaries.

1 wic_table_object

Two new tables (plus a labels support) are added to the logical table dictionary.

  • wic_table_check_constraints, is added to allow non database checks writen directly in javascript. The motivation is:
    • Provide a new javascript plain syntax (not JUEL)
    • Some constraints can not be enforced in database cause interfaces may need to do some operations not allowed from clients.
    • Avoid to modify existing table wic_jdic_clientchk that will remain unmodified
  • wic_table_check_constraints_labels with the localized lables for the check to avoid use the general lables table.
  • wic_table_foreign_keys, is added to allow to enforce application foreign keys. The motivation is:
    • Some physical constraints can't be enforced some times for performance degradation
    • Avoid to use existing table for similar purpose wic_jdic_softref?????

Schema proposal:

Copy
<table name='wic_table_check_constraints_labels'>

   <!-- COLUMNS -->
   <column name='label_code'  type='char'     size='40'            required='y'    info='Code of label'/>
   <column name='locale'      type='char'     size='2'             required='y'    info='Language en,es,ca...' />
   <column name='label_name'  type='varchar'  size='255'           required='y'    info='Description of label'/>
   
   <!-- INDEXES -->
   <index name='u_wic_table_check_constraints_labels1' columns='label_code,locale' unique='y' />
   
</table>

<table name='wic_table_check_constraints'>

   <!-- COLUMNS -->
   <column name='check_id'         type='serial'                                                  required='y'  info='Identifier'/>
   <column name='tab_name'         type='char'           size='48'                                required='y'  info='Refer to wic_table_object'/>
   <column name='label_code'       type='char'           size='40'                                required='y'  info='Refer to wic_table_check_constraints_labels'/>
   <column name='constraint_data'  type='lvarchar'       size='512'                               required='y'  info='Javascript plain syntax'/>

   <column name='user_created'     type='char'           size='20'              default='user'    required='y' />
   <column name='date_created'     type='datetime'       size='year to second'  default='current' required='y' />
   <column name='user_updated'     type='char'           size='20'              default='user'    required='y' />
   <column name='date_updated'     type='datetime'       size='year to second'  default='current' required='y' />

   <!-- INDEXES -->
   <primary name='p_wic_table_check_constraints' columns='check_id' />

   <!-- FOREIGN KEYS -->
   <foreign name='f_wic_table_check_constraints1' columns='tab_name'   references='wic_table_object'                   refcols='tab_name' ondeletecascade='y' />
   <foreign name='f_wic_table_check_constraints2' columns='label_code' references='wic_table_check_constraints_labels' refcols='label_code'  />
   
</table>

<table name='wic_table_foreign_keys'>

   <!-- COLUMNS -->
   <column name='fk_id'            type='serial'                                                  required='y'  info='Identifier'/>
   <column name='tab_name'         type='char'           size='48'                                required='y'  info='Refer to wic_table_object'/>

   <column name='fk_cols'          type='varchar'        size='80'                                required='y'  info='Columns used at fk'/>
   <column name='pk_table'         type='char'           size='48'                                required='y'  info='Destination table'/>

<!-- Needed ?? -->
<column name='pk_cols'          type='varchar'        size='80'                                required='y'  info='Columns used at destination table'/>

   <column name='user_created'     type='char'           size='20'              default='user'    required='y' />
   <column name='date_created'     type='datetime'       size='year to second'  default='current' required='y' />
   <column name='user_updated'     type='char'           size='20'              default='user'    required='y' />
   <column name='date_updated'     type='datetime'       size='year to second'  default='current' required='y' />

   <!-- INDEXES -->
   <primary name='p_wic_table_foreign_keys' columns='fk_id' />

   <unique name='u_wic_table_foreign_keys1' columns='tab_name,pk_table'/>

   <!-- FOREIGN KEYS -->
   <foreign name='f_wic_table_foreign_keys1' columns='tab_name' references='wic_table_object' refcols='tab_name'  ondeletecascade='y' />
   
</table>

Most common Database checks

Copy
<check name='c_pos_warehouse1'>
     <constraint>
      whs_state IN ('A','B')
    </constraint>
</check>

<check name='c_pos_printer_tickets_1'>
    <constraint><![CDATA[
        (print_template_type IN(0,1,2,3))
    </constraint>
</check>

<check name='c_pos_payment1'>
    <constraint><![CDATA[
     ((pay_type = 'VOUCHER' AND voucher_type IS NOT NULL) OR (pay_type != 'VOUCHER'))
    </constraint>
</check>

<check name='c_pos_rate_item1'>
    <constraint><![CDATA[
        (item_dtouni <= 100) OR (item_dtouni >= -100)
    </constraint>
</check>

<check name='c_pos_promotion4'>
    <constraint><![CDATA[
        from_price >= 0
    </constraint>
</check>

<!-- Only one of this columns must be informed  product, tag, home, category, provider, brand -->
<check name='c_pos_ecom_card_items1'>
    <constraint>
        ((product_id IS NOT NULL AND tag_id IS NULL AND home_id IS NULL AND page_id IS NULL   AND category_id IS NULL AND provider_id IS NULL AND brand_id IS NULL) OR 
         (product_id IS NULL AND tag_id IS NOT NULL AND home_id IS NULL AND page_id IS NULL   AND category_id IS NULL AND provider_id IS NULL AND brand_id IS NULL) OR
         (product_id IS NULL AND tag_id IS NULL AND home_id IS NOT NULL AND page_id IS NULL   AND category_id IS NULL AND provider_id IS NULL AND brand_id IS NULL) OR
         (product_id IS NULL AND tag_id IS NULL AND home_id IS NULL AND page_id IS NOT NULL  AND category_id IS NULL AND provider_id IS NULL AND brand_id IS NULL) OR
         (product_id IS NULL AND tag_id IS NULL AND home_id IS NULL AND page_id IS NULL  AND category_id IS NOT NULL AND provider_id IS NULL AND brand_id IS NULL) OR
         (product_id IS NULL AND tag_id IS NULL AND home_id IS NULL AND page_id IS NULL  AND category_id IS NULL AND provider_id IS NOT NULL AND brand_id IS NULL) OR
         (product_id IS NULL AND tag_id IS NULL AND home_id IS NULL AND page_id IS NULL  AND category_id IS NULL AND provider_id IS NULL AND brand_id IS NOT NULL) OR
         (product_id IS NULL AND tag_id IS NULL AND home_id IS NULL AND page_id IS NULL  AND category_id IS NULL AND provider_id IS NULL AND brand_id IS NULL)
         )
    </constraint>
</check>

Rare Database checks

Copy
<check name='c_ccalhorl1'>
    <constraint><![CDATA[
        (((horini != '00:00' AND horini IS NOT NULL) OR (horfin != '00:00' AND horfin IS NOT NULL)) AND (hornum >0 AND hornum IS NOT NULL)) OR
        (horini IS NULL AND horfin IS  NULL AND hornum IS NULL)
    </constraint>
</check>

<check name='c_cgconoth2'>
    <constraint>
        <extend from='year' to='day'>date_created</extend> = <extend from='year' to='day'>date_updated</extend>
    </constraint>
</check>

<check name='c_csalprog1'>
    <constraint>
        <substr>agrupa, 1, 1</substr> BETWEEN 'A' AND 'Z'
    </constraint>
</check>
   <!-- Ifx explain: c_csalprog1 ((SUBSTR (agrupa ,1 ,1 )>= 'A' ) AND (SUBSTR (agrupa ,1 ,1 )<= 'Z' ) ) -->

   <check name='c_csepadom2'>
        <constraint>
            ((estado = 1       AND file_data IS     NULL AND numope = 0) OR
             (estado IN (2, 3) AND (file_data IS NOT NULL OR fecfir = <mdy m='10' d='31' y='2009'/>)))
        </constraint>
    </check>
    
<check name='c_cserdoch2'>
    <constraint>
        (lenjus BETWEEN 0 AND (20-<length>codigo</length>))
    </constraint>
</check>

<check name='c_cserdoch6'>
    <constraint>
        <substr>codigo, <length>codigo</length>, 1</substr> IN ('-','/','.')
    </constraint>
</check>

<check name='c_cserdoch6'>
    <constraint>
        codigo[1] IN ('-','/','.')
    </constraint>
</check> 

<check name='c_galmubim2'>
     <constraint>
     horfin &gt;= horini
     </constraint>
</check>

<check name='c_gcomacuh7'>
    <constraint>
        (impant + CASE WHEN impant_ntax IS NULL THEN 0 ELSE impant_ntax END) = 0 OR (impant + CASE WHEN impant_ntax IS NULL THEN 0 ELSE impant_ntax END) <= imptot
    </constraint>
</check>

2 SoftReference

2.1 History (wic_jdic_collist)

2.2 Softreference V1

2.2.1 Softreference Definition

Soft References (or Filtering Helper) is a powerful tool to ease form data entry and to enable client side data validation. It is useful when a form contains a field which value must be previously registered into a database table. So, it helps in the selection of the field's value and integrity verification.

The main purposes of Filter helper are:

  • Autocomplete: Field autocompletion evaluates the text typed by the user on those fields where Filtering Help is enabled. While the user is typing the form displays a list of matching values for helping the user to select the right value.
  • Data validation: After the user has filled the field, the system verifies that the entered data exists in the helper destination table, according to the Soft References definition.
  • Importing related data: After the user has filled the field the system could obtain some data related to the entered value for filling some other fields or views in form. For example, you can retrieve the bank account number after informing of the client's name. Related data obtaining is executed together with data validation, in order to improve network communication and server workload.
  • Object data selector: In case of the user requires to execute complex queries, it is possible to access an Axional Studio SQL Report for filtering and getting the field value. So, that implementation takes profit of the power of Axional Studio Query By Example Form (QBE).
  • Custom validation messages: It allows Soft References to display data as selectable on autocomplention or object selector list, but once selected blocks the field with an error message.It is useful, for example, for discarded or deprecated data. Hiding this data from list could be interpreted as the data doesn't exists on destination table; through this implementation data is shown but it can not be selected.


wic_jdic_softref_help
Label Description
Table Physical table name which is the data source
Method Code which in combination with table name identifies the Helper
Table quick edititon

With this table user can register a new record without having to access the original form that defines that field. To create a new record, the user must click on the ADD NEW option located in the drop-down menu of options in that field.

Helper object column Column name from which get the value in the data selector object
Condition Filtering condition restricting displayed rows in the data selector object

Autocomplete

By default, the autocomplete functionality should return a light list of records (20 or 25 rows).

Likewise, the speed of response is essential and therefore it must interrogate following indexes in the database.

The statement is defined with two fields. Usually:

  1. Value code that is incorporated into the field
  2. Accessory value description for easy search

The descriptive value can be a field value to a combination of fields. For example: "[" || code "]" || name "(" cif ")" " The output sort is not preset and depends on the definition in this field.



Autocomplete QBE

By default, the autocomplete functionality should return a light list of records (20 or 25 rows).

Likewise, the speed of response is essential and therefore it must interrogate following indexes in the database.

The statement is defined with two fields. Usually:

  1. Value code that is incorporated into the field
  2. Accessory value description for easy search

The descriptive value can be a field value to a combination of fields. For example: "[" || code "]" || name "(" cif ")" " The output sort is not preset and depends on the definition in this field.

Validation

The validation statement has two purposes: verify the integrity of the input value and gather some information related to the input value for filling the form with this data.

These purposes are achieved by executing the Validation SQL statement when the field value changes. Basically, execution of this statement is triggered by:

  • The user has manually modified the field and leave it.
  • The user selects a value from the autocomplete list.
  • The user selects a value from object selector list.
  • The field has been changed by the client side Javascript program.

As it happens with the autocomplete statement, leaving the Validation SQL statement blank entails the system to build an automatic statement using the helper definition table and method.



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

2.2.2 Softreference Relations

Once having a proper catalog of Soft References is the time of telling each field which soft reference will use and configure the relations between the form and the soft reference. So, defining Soft Relations allows:

  • Assign a Soft References to a field
  • Map form data with the corresponding variables used in the soft reference.
  • Assign data returned by helper validation statement to be filled in form fields.


wic_jdic_softref_rel
Label Description
Table Code of the object in which the "soft reference" is included
Source column Column of the form in which the "soft reference" is included. In this column the filter criteria referenced in the table and filter method will be applied.
Form enabled condition

Evaluation condition to apply the filter. This condition is written in javascript and it is evaluated on the client at runtime.
Multiple soft references can be entered for the same pair of object and source column with different activation conditions.

For example, "${tabori}" == "gvenpedh" that this filter should be taken into account only when the content of the "tabori" field in the form is equal to gvenpedh.

Allows you to use any field entered in the output of the "wic_jrep_colout" object.

In addition, it is possible to retrieve variables from the parent form using parent(field1).

Replaces the functionality of SetExistValue.



  • Format: JS_EXPR
Filtering table

It allows to indicate the "soft reference" helper to be used to validate the source column.

A "soft reference" helper allows you to define the SQL statements for obtaining the list of available data and the condition for its validation. Its identification is defined by a table and a method code.

Therefore, the value of this field indicates the table defined in wic_jdic_softref_help.sref_tabname

Method It contains the method used in the definition of the "soft reference" helper.
SQL Vars (Form:SQL)

When in a "soft reference" the variables are used in the SQL statements, we must provide a map that relates the fields of the form with the variables used in the SQL. The syntax of this map is JSON.

For example, if in a form we have a delegation field and in the SQL the variable ${delega} is used, we must provide a map such as:

{"delegation":"delega"}



  • Format: PARSEJSON
Column mapping (Form:SQL)

Sets a map that allows you to retrieve returned columns by the validation select of the "soft reference" and applies them to form fields. All those columns that are not included in the map will not be assigned in the form even if the SQL statement selects them. The syntax of this map is JSON.

For example, if in a form we have a delegation field and the validation SQL returns a "delega" column, we must provide a map such as:

{"delegation":"delega"}



  • Format: PARSEJSON
Disable clear

Usually, when the value of a field is modified with a "soft reference", the dependent values of this field are cleared. This indicator allows this mechanism to be disabled, maintaining the value of the related fields.



  • Default: 0
  • Values:
    • 1: Yes.
    • 0: No.
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

2.2.3 Flow of execution

The following chart tries to explain the architecture and the system behavior of fields filtering helpers. The graph includes the whole application flow, from the user interaction to the database access. The purpose of this graph is to explain what processes intervene in the execution of filtering helpers and where are executed (client/server).

Loading...