A Transaction Manager is a component of wic_jrep_object to trigger actions after events.

A Transaction Manager allows defining actions interposed to the events of INSERT, DELETE, UPDATE or RESET of a SQL object acting as a program trigger (non-resident in database).

The table wic_jrep_trxmgr allows you to define the transaction handler for an object.

The code of an event accepts both SQL functions and calls to XSQL (scripts) can refer to values of the row that processed.

The operations on existing rows (UPDATE or DELETE) can use any value of the row through the reference operator #.

During the loading of a form, the system executes different inspection and data search processes, in order to preload, when possible and is defined, a subset of field values.

Before and after an INSERT you can do actions like update other tables of the database with values of the row that processed.

This is the flowchart of the transaction:

Before and after an UPDATE you can do actions like update other tables of the database with values of the row that processed.

This is the flowchart of the transaction:

This case is practically the same as INSERT and DELETE, but with a particular case.

Before and after an DELETE you can do actions like update other tables of the database with values of the row that deleted.

This is the flowchart of the transaction:

Current section shows some useful examples with the most common uses of Transaction Manager. However, this tecnology is totally open and highly expandable, so feel free for using your own implementation and not be limited by this samples.

In this example, before an INSERT transaction the Transaction Manager will be called and a new row will be added before the transaction.

INSERT INTO studio_trx1 (field_char1) VALUES ('TRX2');

In this example, we will create some Transaction Managers to generate Logs from the transactions that we do in a table.

We will only define the Transaction Managers of the UPDATE for simplicity.

INSERT INTO studio_log (log_message, log_char) VALUES ('Prepared to update a value.', ${field_char1});

INSERT INTO studio_log (log_message, log_id) VALUES ('Value updated!.', ${field_id});

Form Actions is an abstract parameterization of actions which can be triggered from the allowed components of an Axional Studio Formauto.

Actions can be triggered from different components. Let's see some examples:

Example

Button that triggers an action

Context menu with some actions

SQL Table with column actions

Copy

executeFormAction("ACTION_EXEC_STMT");

JS function to call an action from its mnemonic

The purpose of this abstract parameterization is to unify all the ways to execute actions and prepare the framework for increasing this ways.

Even so, each form of triggering an action will have its particularities, which will be explained later.

Form actions are mainly focused on the execution of client or server actions, such as update a row of a table or show an alert on the navigator.

Its use is interesting when:

• An action has to be done to an object (with a button)
• An action has to be done to a row of a table (with an action on context menu of an SQL Table, or with a column action)
• A new window with a dynamic URL has to be opened
• And many more uses...

The best thing of form actions is that by separating the parameterization, the code will be much more efficient and less redundant, taking advantage of it much more.

In first place, Table Colorizer requires the basic Axional Studio infrastructure, which includes:

• Axional Studio Server, properly set up.
• Dictionary database
• A target database

In second place, as actions have to be triggered from buttons of Axional Studio Form Object or context menu of rows in SQL Tables, it is required to have at least one cataloged object.

The creation of Form Actions involves three parameterization tables:

• Action definition (wic_jrep_form_action)
• Action fields definition (wic_jrep_form_action_field)
• Action dynamic fields definition (wic_jrep_form_action_dynfield)

As it is explained below, Form Actions functionalities only requires always the table wic_jrep_form_action; It will be explained when is necessary to use the other tables below.

If the action defined has to have fields, another table will be needed to define the action fields:

If the action has to have fields, but we want to define these fields dynamically, the following table will used :

The implementation of Form Actions is achieved by adding a defined action to an element that allow its use.

The implementation of Form Actions is defined by one entity:

• Form actions (wic_jrep_form_action)

The former defines the action, and according to this action involve another entities like form action fields (wic_jrep_form_action_field) and/or form action dynamic fields (wic_jrep_form_action_dyn_field).

The form action contains all the necessary information to execute an action. Each action is identified by a unique id (action_id), and a unique code (action_code) of an object identified by a unique code (rep_code). This unique id can be use by more than one object (from a button and from a context menu, for example).

To start defining our action, the following values will be indicated:

• Identification
  • Code
  • Style
  • Label
  • Icon (not required)
  • Description (not required)
• Authorizations
  • Insert
  • Delete
  • Update
  • Execute
• Checks
  • Validation function (not required)
  • Enable expression (not required)
  • Disable style
• Execution
  • Type
  • Update mode
  • Output type
  • Confirm
  • Statement
• Form options
  • Title (not required)
  • Size
• Iteration
  • Iteration statement (not required)
  • Iteration group
• Message statement (not required)

The Mnemonic Code identifies the action univocally within the object.

The Style determines the action sensivility to the trigger element.

Example

According to the style selected the button will have the corresponding color:

The Label determines the text to be put on the trigger element. It could be:

• A label code defined previously on wic_jdic_lbldata
• An UEL expression (generally when iteration statement is defined)

The Icon identifies the icon code to be put on the trigger element. It is not required. It could be:

• An image code defined previously on wic_image_object
• An UEL expression (when iteration statement is defined)

The Description contains the functional description of the action. It is not required.

The Insert flag indicates whether the context where the action is applied must have INSERT permission or not.

• False: Insert permission not required
• True: Insert permission required

The default value is true.

The Delete flag indicates whether the context where the action is applied must have DELETE permission or not.

• False: Delete permission not required
• True: Delete permission required

The default value is true.

The Update flag indicates whether the context where the action is applied must have UPDATE permission or not.

• False: Update permission not required
• True: Update permission required

The default value is true.

The Execute flag indicates whether the context where the action is applied must have EXECUTE permission or not.

• False: Execute permission not required
• True: Execute permission required

The default value is true.

The Validation function is a JS code executed before start action execution, or before showing action form if necessary. It is not required.

The Enable expression determines with a client side UEL expression if the action is enabled. It is not required.

The Disable style determines if a disabled action has to be disabled or hidden.

The default value is Disabled.

The execution Type determines the type or language of the code defined in the execution statement.

• Client Side (Javascript)
• Server Side (SQL, XSQL, Javascript)

The default value is Server Side.

The Update mode flag determines how to update the context data of the action that is applied.

• No refresh
• Refresh row
• Refresh cursor
• Refresh box

The default value is No refresh.

The Output type flag determines what type of response will be issued after action execution.

• None
• Message
• Datatable
• URL Modal
• URL New window
• URL Refresh window

The Confirm flag indicates whether the user has to confirm before the execution of the action.

• False: Confirmation is not required
• True: Confirmation is required

The default value is true.

The execution Statement determines the main action statement executed after confirm the action.

Generally contains the action program (the code executed to implement the action functionality).

The form Title identifies the label code associated with the fields form title, that contains the text to be put as a header of the form that appears before the execution of the action statement.

The label code must be previously defined previously on wic_jdic_lbldata.

The form Size determines the size of the fields form. There are four sizes predefined:

• Auto (Adapted to number and size of the fields)
• Small
• Medium
• Big

The default value is Auto.

The Iteration statement contains the SQL Statement for implementing action iteration. Action iteration allows having dynamic actions.

In consequence, the current statement must return a Result Set, and each row of the Result Set will be an action.

The Iteration group flag determines if iteration column actions are shown compacted on a drop down list or as separated column buttons.

The default value is false.

The Message statement is an SQL Statement for retrieving a message to be shown in the top of the action form.

The statement must return a Result Set of one row and one column. Otherwise, the message should not be shown properly.

Actions can have fields to obtain necessary information to be executed, in this case for any necessary field to be created it will be necessary an instance of wic_jrep_form_action_field with the following values:

• Identification
  • Position
  • Table (not required)
  • Column
  • Type
  • Size
  • Default (not required)
• Input options
  • Editable
  • Nullable
  • Lettercase
  • Disable expression (not required)
• Soft reference options
  • Table (not required)
  • Method (not required)
  • Input mapping (not required)
  • Output mapping (not required)

The Position determines the order of appearance of the field in form.

The Table identifies the name of the table the column name belongs to.

If there is no table defined, the system will consider the primary table of te main cursor as the table of the field.

The Column name identifies the field univocally within the button form.

The field label will be determined from the combination of field_tabname and field_colname.

The Type determines the entry conditions and format of the data. It can have these values:

• CHAR
• INTEGER
• DECIMAL
• DATE
• DATETIME

The default type is CHAR.

The Size determines the maximum number of characters for the field. If zero, there is no maximum number.

The default value must be 0.

Example

This is a field of an action with field_size = 10.

The Default value determines the initial value for the field.

It could be a constant or a UEL expression.

The Editable flag determines whether the field is writable or read only.

• False: Read only
• True: Writable

The default value is true.

The Nullable flag determines whether the capability of letting the field blank or not.

• False: Can not be blank
• True: Can be blank

The default value is true.

The Lettercase transform determines if the field text must be transformed after typing.

• None: Do not apply any conversion
• Uppercase: Converts the value to uppercase letters
• Lowercase: Converts the value to lowercase letters

The default value is None.

The Disable expression is an UEL expression which dynamically determines if the field is editable or not.

• True: The field will not be editable
• False: The field will be editable

In case of the expression use action fields, the field entry property might change while filling the form.

The Table identifies the soft reference table identifier.

In combination with field_sref_method determines the soft reference to apply to the field.

The Method identifies the soft reference identifier.

In combination with field_sref_tabname determines the soft reference to apply to the field.

The Input mapping contains the columns mapping from action fields to soft reference.

The Output mapping contains the columns mapping from soft reference to action fields.

Action fields can also be created dynamically.

In this case it is necessary to create instances of wic_jrep_form_action_dynfield with the statement that will return the result set with the information of the fields.

The columns of wic_jrep_form_action_dynfield are practically the same as the columns of wic_jrep_form_action_field (except field order), with the difference than for dynamic fields the mapping column of the statement is set, because the result set will contain the information to generate the fields.

To obtain this information the fields_stmt has to be set, like here:

<select>
    <columns>*</columns>
    <from table='studio_form_action_dynfields' />
    <where>dyn_action = 'ACTION_1300'</where>
    <order>dyn_order</order>
</select>

Then, use the columns of the statement to set the mapping to generate the fields.

A Form Action can be triggered from different elements within a Form:

• Form Buttons (wic_jrep_form_butt)
• SQL Boxes Context Menu (wic_jrep_box_celldata_action)
• SQL Boxes Columns (wic_jrep_box_sqltable_out)
• Client side Javascript call

While Form Buttons, SQL Boxes Context Menu and SQL Boxes Columns are used on server side, the JS call from a function will be explained in the Client Side section.

To start defining a button, the following values will be indicated:

• Action Id
• Position
• If row selected
• If parent
• Enable condition
• Cache
• Script event (deprecated)

The Action Id identifies univocally the referenced action in the dictionary.

The Position indicates the order of the action on form/box.

The If row selected flag indicates if the button is enabled or not depending on reset.

• True: The button will be enabled only if there is some register in the cursor.
• False: The button will appear always.

The If parent flag indicates if the button is enabled or not depending on object parent.

• True: The button will appear only if the current object has parent.
• False: The button will appear independently of the object parent.

The Enable condition indicates if the button is enabled from an UEL/SQL expression. It is not required (in this case the button will be enabled).

• True: The button will be enabled.
• False: The button will be disabled.

The Cache flag indicates if the enable condition of the button will be saved on the cache to avoid to execute again the sentence.

The Script event is a JS function to trap and modify initial vdata.

To start defining a context menu, the following values will be indicated:

• Action Id
• Position

The Action Id identifies univocally the referenced action in the dictionary.

The Position indicates the order of the action on context menu.

To start defining a column action of a column defined in a sqltable, the following values of this column will be indicated:

• Action Id

The Action Id identifies univocally the referenced action in the dictionary.

According to the object that triggers the action, some implementations of form actions will be enabled or disabled. Below is a diagram indicating which columns of wic_jrep_form_action are used according to the trigger object of the action:

The following section presents a set of samples with some interesting cases of uses of Axional Studio Form Actions implementations:

This sample shows how to implement a defined Form Action in a JRep Object that can be triggered from a button.

This sample will depend on a table from wic_studio called studio_actions_flow with the information of the iteration flow of the action. It will contain this data:

The form action parameterization for that case consists of:

<script>
    var p_serial = Ax.context.adapter.action_index;
    var p_next = Ax.db.executeGet(
            "SELECT next FROM studio_actions_flow WHERE description = ? AND action = ?",
            Ax.context.field.reason, Ax.context.adapter.action_state
        );
    Ax.db.update("studio_actions_iteration", {action_index: p_serial, action_state: p_next});
</script>

<select>
	<columns>
		action, next, description
	</columns>
	<from table='studio_actions_flow' />
	<where>
		action = ${action_state}
	</where>
</select>

The action created before will have a field to indicate the action to do, and will be parameterized this way:

Finally, the form button has to be parameterized to have a trigger to execute the action. In that case consists of:

Once form action is defined and assigned to a button, when the object is called will appear the button in the bottom of the navigator.

Considering that the instance of the object where the cursor is located has action_state = 0, this will be the appearance of the displayed object:

When the button is clicked, a form with the paramaterized field before will appear:

Then, after confirm the action will be executed and the row will be refreshed like it was parameterized before. Now, the appearance of the displayed object will be this:

This sample shows how to implement a defined Form Action in a JRep Object that have to be triggered from the context menu of a SQL Table (the context menu will know the data of the row clicked).

The form action parameterization for that case consists of:

<script>
    var p_serial = Ax.context.data.serial_auto;
    Ax.db.delete("studio_trx1", {serial_auto: p_serial});
    return 'Row with serial_auto = ' + p_serial + ' deleted correctly!';
</script>

<script>
    var p_serial = Ax.context.data.serial_auto;
    
    return 'Do you want to delete the row with serial auto = ' + p_serial + '?';
</script>

Finally, the context menu of the SQL Table has to be parameterized to have a trigger to execute the action. In that case consists of:

Once form action is defined and assigned to a context menu, when a SQL Table row is clicked the context menu will appear with the created action.

When the action is clicked, a form with a message will appear:

Then, after confirm the message received in the form, another confirmation will appear (the Confirm flag is set to true):

Then, after confirm the action will be executed and the row will be deleted, finally a message will appear and the SQL Table will be refreshed. Now, the appearance of the displayed object will be this: