Within each form it is possible to deal with transactions DML. Next chapters detail main aspects of each type of data manipulation

1 TX Manager

1.1 Introduction

1.1.1 What is it?

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

1.1.2 What can I do?

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).

1.2 Arquitecture

1.2.1 Structure





1.2.2 Dictionary tables

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

wic_jrep_trxmgr
Label Description
Object Object code
Type Event type

• Default: 0
• Values:
• 0: Insert.
• 1: Delete.
• 2: Update.
• 4: Reset.
Execute always Call mode to transaction manager

• Default: 0
• Values:
• 1: Yes.
• 0: No.
When Moment to execute statement

• Values:
• 0: Before.
• 1: After.
When Moment to execute statement

• Values:
• 0: Before and Continue.
• 1: Before, Commit and Not Continue.
• 2: After.
trx_refresh
Condition order Condition order

• Default: 0
Javascript condition Javascript condition for execute statement

• Format: UELSQL_EXPR
Return Return function action code

• Values:
• 0: Continue.
• 1: Rollback.
• 2: Commit and not continue.
• 3: Commit, not continue and refresh.
Statement Statement to execute

• Format: SQLCOND_EXPR
trx_stmt_backup
User created User that has created the object

• Default: USER

• Default: CURRENT
User updated User that has updated the object

• Default: USER
Date updated Last update date

• Default: CURRENT

1.3 Implementation

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 #.

The operations of INSERT can only operate if the table has a field serial or primary key. Therefore, if the table does not have an univocal reference value, the event INSERT can not be executed since after the operation the inserted row can not be determined.

1.3.1 Reset

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.

1.3.2 Insert

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:





Javascript Condition

To execute the TX Manager the javascript condition must be met, if not we will continue with the flow of the transaction as if it didn't exist.

Exception

Any exception called during the flow of the transaction will cause a ROLLBACK of the connection, erasing any changes made.

1.3.3 Update

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 Continue Always*

If we UPDATE without changes and exists a TX Manager of type Before and Continue Always we will run this TX Manager and we will continue with the flow as if there had been a transaction (as long as the condition is met).

This case is used to set values with a call into script, if it's used in another way, it won't work.

Javascript Condition

To execute the TX Manager the javascript condition must be met, if not we will continue with the flow of the transaction as if it didn't exist.

Exception

Any exception called during the flow of the transaction will cause a ROLLBACK of the connection, erasing any changes made.

1.3.4 Delete

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:





Javascript Condition

To execute the TX Manager the javascript condition must be met, if not we will continue with the flow of the transaction as if it didn't exist.

Exception

Any exception called during the flow of the transaction will cause a ROLLBACK of the connection, erasing any changes made.

1.4 Samples

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.

1.4.1 Insert a row before an Insert

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

Example
• trx_type: Insert
• trx_exec_when: Before and Continue
Copy
INSERT INTO studio_trx1 (field_char1) VALUES ('TRX2');

If 'field_char1' is primary key?

This is a bad implementation for Transaction Manager because it will only work when the table is empty. After the first transaction, the Transaction Manager will always generate an exception because there will already be a field with these values.

1.4.2 Add a log before and after a transaction

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.

Example
• trx_type: Update
• trx_exec_when: Before and Continue
Copy
INSERT INTO studio_log (log_message, log_char) VALUES ('Prepared to update a value.', ${field_char1}); Example • trx_type: Update • trx_exec_when: After Copy INSERT INTO studio_log (log_message, log_id) VALUES ('Value updated!.',${field_id});

TO DO

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

2 Form Actions

2.1 Introduction

2.1.1 What is it?

Form Actions is an abstract parametrization 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

Copy
executeFormAction("ACTION_EXEC_STMT");

JS function to call an action from its mnemonic

The purpose of this abstract parametrization is 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.

2.1.2 What can I do?

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)
• 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.

2.1.3 What do I need?

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

• Axional Studio Server, properly set up.
• Dictionary database
• A target database
The previous configuration is explained in detail under the Axional Studio/Installation block.

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.

If the action will be called with executeFormAction JS function, this will not be necessary.

2.2 Architecture

2.2.1 Structure





2.2.2 Dictionary tables

The creation of Form Actions involves three parametrization 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.

Action definition

wic_jrep_form_action
Label Description
Action Id

Univocally identifier of a Formauto Action parametrization in the dictionary.

Object Code

Code of the JRepObject the action belongs to.

• Default: THIS
Mnemonic

Mnemotechnic code which identifies the action univocally within the jRepObject.

It is used when is required to have a fixed reference to the action, for example, if is called from a Javascript program.

Description

Functional description of the action.

It can be useful for explaining what this action is for, when can be executed and the consequences of its execution.

Label

Label code associated with the action description. That is, the text to be put on the action trigger element (button, context menu, etc. associated to the action).

The label code must be previously defined in the master of logic dictionary labels (wic_jdic_lbldata).

Optionally, the label code could be a UEL expression. Which allow using dynamic labels, generally when use iteration actions.

• Format: SQLCOND_EXPR
Icon

Icon code associated with the action. That is, the icon to be put on action trigger element.

The icon code must be previously defined in the master of dictionary images (wic_image_object).

Style

Determine the action style; generally, depending on the action sensitivity:

The action style is applied to the action trigger element.

• Default: 0
• Values:
• 0: Default. Default color
• 1: Confirm. Confirm color (green)
• 2: Info. Info color (light blue)
• 3: Warning. Warning color (yellow)
Insert

Flag indicating whether the context where the action is applied must have INSERT permission or not.

In case of the value of this flag will be zero it is not required to have the corresponding permission. Otherwise, it will be required.

• Default: 1
• Values:
• 1: Yes.
• 0: No.
Delete

Flag indicating whether the context where the action is applied must have DELETE permission or not.

In case of the value of this flag will be zero it is not required to have the corresponding permission. Otherwise, it will be required.

• Default: 1
• Values:
• 1: Yes.
• 0: No.
Update

Flag indicating whether the context where the action is applied must have UPDATE permission or not.

In case of the value of this flag will be zero it is not required to have the corresponding permission. Otherwise, it will be required.

• Default: 1
• Values:
• 1: Yes.
• 0: No.
Execute

Flag indicating whether the context where the action is applied must have EXECUTE permission or not.

In case of the value of this flag will be zero it is not required to have the corresponding permission. Otherwise, it will be required.

• Default: 1
• Values:
• 1: Yes.
• 0: No.
Enable expr

Enabling client side UEL expression.

In case of an expression is defined, the action will only be enabled when it is evaluated to TRUE.

• Format: JS_EXPR
Validation function

Javascript code executed before start action execution, or before showing action form is necessary.

If defined, the code will be executed, in case the code returns FALSE the action execution will be prevented. Otherwise, the action will be executed as expected.

This code is useful for applying some verifications in form, such as if there are any row selected.

• Format: JS_EXPR
Form title

Label code associated with the fields form title. That is, the text to be put as a header of the form that appear before executing the action statement.

The label code must be previously defined in the master of logic dictionary labels (wic_jdic_lbldata).

Form size

The size of the fields Form.

• Default: 0
• Values:
• 0: Auto.
• 1: Small.
• 2: Medium.
• 3: Large.
Message stmt

SQL Statement for retrieving a message to be shown in the Action Form. That is, a text to be put at the top of the form that appear before executing the action statement.

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

This message generally contains a brief description of the process that will be executed with the action, and its consequences.

• Format: SQLCOND_EXPR
Requires confirmation

Flag indicating if ask the user for confirmation before executing the action.

In case of the value of this flag will be zero confirmation is not required. Otherwise, the user will be asked for confirmation.

• Default: 1
• Values:
• 1: Yes.
• 0: No.
Execution type

The execution type determines the type or language of the code defined in the execution statement (action_exec_stmt).

• Default: 1
• Values:
• 0: Client side (Javascript). Client side (Javascript)
• 1: Server side (SQL, XSQL, Javascript). Server side (SQL, XSQL, Javascript)
Exec stmt

Main action statement executed when confirm the action.

It generally contains the action program; that is, the code executed to implement the action functionality.

Data update mode

This flag determine how to update the data of the context the action is applied.

• Default: 1
• Values:
• 0: None. None
• 1: Refresh row. Refresh row
• 2: Refresh cursor. Refresh cursor
• 3: Refresh box. Refresh box

This flag determine what type of response will be emitted after action execution. The selected type will condition the action statement response.

• Default: 0
• Values:
• 0: Auto. Auto
• 1: Message. Message
• 2: Datatable. Datatable
• 3: URL New window. URL New window
• 4: URL Modal. URL Modal
• 5: URL Refresh Window. URL Refresh Window
Iteration stmt

SQL Statement for implementing button iteration. Button iteration allows having dynamic buttons.

In consequence, the current statement must returned a ResultSet; each row of the ResultSet will be a button.

• Format: SQLCOND_EXPR
User created User that has created the object

• Default: USER
Date created Creation date

• Default: CURRENT
User updated User that has updated the image

• Default: USER
Date updated Updated date

• Default: CURRENT

Action fields definition

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

wic_jrep_form_action_field
Label Description
Action Id

Formauton Action identifier the action fields belongs to.

Position

Determines the order of appearance of the field in form.

Column

The column name identifies the field univocally within the Button Form.

The combination of field_tabname and field_colname columns determines the field label.

Table

Name of the table the column name belongs to.

If there is not table defined, the system will consider the primary table of the main cursor as the table of the field column name.

Default

Initial value for the field.

It could be either a constant or a UEL expression.

Type

The field type determine the entry conditions and format of the data.

• Default: 1
• Values:
• 1: CHAR.
• 4: DATE.
• 3: DECIMAL.
• 2: INTEGER.
• 5: DATETIME.
Size

Field size determine the maximum number of characters for the field.

If zero, there is not maximum number.

Entry

Field entry is the capability of whether the field is writable or read only.

If the corresponding value is zero the field is read only; otherwise, is writable.

• Default: 1
• Values:
• 1: Yes.
• 0: No.
Nullable

Field nullability is the capability of whether letting the field blank or not.

If the corresponding value is zero the field can not be let blank; otherwise, it can.

In case of letting blank any required field the Button Form can not be submitted, so the action can not be executed.

• Default: 1
• Values:
• 1: Yes.
• 0: No.
Lettercase

Letter case transform determines if the field text must be transformed after typing.

• Default: 0
• Values:
• 0: None. None
• 1: Uppercase. Uppercase
• 2: Lowercase. Lowercase
Condition disable

UEL expression which dynamically determines if the field is editable.

If defined, in case of the expression is evaluated to TRUE the field will not be editable, even if the field_is_entry field is enabled.

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

• Format: UELSQL_EXPR
Filtering table

Soft Reference table identifier.

In combination with field_sref_method determines the Soft Reference to apply to the field.

Method

Soft Reference method identifier.

In combination with field_sref_tabname determines the Soft Reference to apply to the field.

SQL vars (Form:SQL)

Columns mapping from button fields to Soft Reference.

• Format: PARSEJSON
Column mapping (Form:SQL)

Columns mapping from Soft Reference to button fields.

• Format: PARSEJSON

Action dynamic fields definition

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

wic_jrep_form_action_dynfield
Label Description
Action Id

Formauton Action identifier the action fields belongs to.

Position

The position of the field is merged with the definition of normal fields.

Statement

Contains the statement which will return a ResultSet with the list of columns.

• Format: SQLCOND_EXPR
Table

Contains the name of the column in the ResultSet referencing the table the field column name belongs to.

If set this attribute blank, or the value of this column in the ResultSet is NULL, the system will consider the primary table of the main cursor as the table of the field column name.

Column

Contains the name of the column in the ResultSet referencing the field column name.

The column name identifies the field univocally within the Button Form.

The combination of fields_tabname and fields_colname columns determines the field label.

Default

Contains the name of the column in the ResultSet referencing the field default value.

If set this attribute blank, or the value of this column in the ResultSet is NULL, the field will not have default value.

Type

Contains the name of the column in the ResultSet referencing the field type.

If set this attribute blank, or the value of this column in the ResultSet is NULL, the field type will be CHAR.

Size

Contains the name of the column in the ResultSet referencing the field size.

Field size determine the maximum number of characters a field can hold. If zero, there is not maximum number.

If set this attribute blank, or the value of this column in the ResultSet is NULL, the field size will be zero; so no maximum will be applied.

Entry

Contains the name of the column in the ResultSet referencing the field entry type.

Field entry is the capability of whether the field is writable or read only. If the corresponding value in ResultSet is zero the field is read only; otherwise, is writable.

If set this attribute blank, or the value of this column in the ResultSet is NULL, the field is writeable.

Nullable

Contains the name of the column in the ResultSet referencing the field nullability.

Field nullability is the capability of whether letting the field blank or not. If the corresponding value in ResultSet is zero the field can not be let blank; otherwise, it can.

If set this attribute blank, or the value of this column in the ResultSet is NULL, the field can be let blank.

Lettercase

Contains the name of the column in the ResultSet referencing the field letter case conversion.

Letter case transform determines if the field text must be transformed after typing.

If set this attribute blank, or the value of this column in the ResultSet is NULL, the field text will not be converted.

Filtering table

Contains the name of the column in the ResultSet referencing the Soft Reference table identifier.

In combination with field_sref_method determines the Soft Reference to apply to the field.

Method

Contains the name of the column in the ResultSet referencing the Soft Reference method identifier.

In combination with field_sref_tabname determines the Soft Reference to apply to the field.

SQL vars (Form:SQL)

Contains the name of the column in the ResultSet referencing the columns mapping from button fields to Soft Reference.

Column mapping (SQL:Form)

Contains the name of the column in the ResultSet referencing the columns mapping from Soft Reference to button fields.

2.3 Implementation

The implementation of Form Actions is achieved by adding a defined action to a 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).

2.3.1 Form action

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).

Defining a form action

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)
• Execution
• Type
• Update mode
• Output type
• Confirm
• Statement
• Form options
• Title (not required)
• Size
• Iteration statement (not required)
• Message statement (not required)

Identification

Code

The Mnemonic Code identifies the action univocally within the object.

Style

The Style determines the action sensivity to the trigger element.

Example

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

Only enabled on buttons

Action style is only applicable on buttons (wic_jrep_form_butt).

Label

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)

Icon

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

The icon code must be previously defined on wic_image_object.

Action icon is only applicable on context menu of SQL boxes (wic_jrep_box_celldata_action).

Description

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

Authorizations

Insert

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.

Disabled on SQL Tree context menu

Action can insert is not applicable on SQL Tree context menu (wic_jrep_box_celldata_action).

Delete

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.

Disabled on SQL Tree context menu

Action can insert is not applicable on SQL Tree context menu (wic_jrep_box_celldata_action).

Update

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.

Disabled on SQL Tree context menu

Action can insert is not applicable on SQL Tree context menu (wic_jrep_box_celldata_action).

Execute

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.

Only enabled on buttons

Action style is only applicable on buttons (wic_jrep_form_butt).

Checks

Validation function

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

Enable expression

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

Execution

Type

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.

Update mode

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.

Only enabled on Server Side

Update mode is only enabled if execution type of action is Server Side. Otherwise, the context will not be refreshed.

Output type

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 selected type will condition the action statement response.

Only enabled on Server Side

Update mode is only enabled if execution type of action is Server Side. Otherwise, the context will not be refreshed.

Confirm

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.

Statement

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).

Form options

Title

The form Title identifies the label code associated with the fields form title, thaht 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.

Size

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.

Iteration statement

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.

Only enabled on buttons

Action style is currently only applicable on buttons (wic_jrep_form_butt).

Message statement

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.

Defining action fields

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)

Identification

Position

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

Order of fields

The column field_order of the tables wic_jrep_form_action_field and wic_jrep_form_action_dynfield are related to each other.

Table

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.

Column

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.

Type

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.

Size

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.

Default

The Default value determines the initial value for the field.

It could be a constant or a UEL expression.

Input options

Editable

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

• True: Writable

The default value is true.

Nullable

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.

Lettercase

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.

Disable expression

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.

Soft reference options

Table

The Table identifies the soft reference table identifier.

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

Method

The Method identifies the soft reference identifier.

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

Input mapping

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

Output mapping

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

Defining fields dynamically

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 setted, because the result set will contain the information to generate the fields.

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

Copy
<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.

Order of fields

The column field_order of the tables wic_jrep_form_action_field and wic_jrep_form_action_dynfield are related to each other.

2.3.2 Action triggers





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)
• Client side Javascript call

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

Form Buttons

Dictionary
wic_jrep_form_butt
Label Description
Identifier Internal ID Button
box_id
Code of the object Object Code

• Default: THIS
Action Id Action Identifier
Position Button Position
Type Type of sentence to execute.

• Default: 3
• Values:
• 1: Execute.
• 3: Execute and refresh.
• 0: Execute And Refresh Cursor.
• 2: Javascript function.
Name Button name

• Format: SQLCOND_EXPR

• Case: Upshift
Width Window Width
Height Window Height
Style Button style

• Default: 0
• Values:
• 0: Default. Default color
• 1: Confirm. Confirm color (green)
• 2: Info. Info color (light blue)
• 3: Warning. Warning color (yellow)
If canInsert If can Insert

• Default: 1
• Values:
• 1: Yes.
• 0: No.
If canDelete If can Delete

• Default: 1
• Values:
• 1: Yes.
• 0: No.
If canUpdate If can Update

• Default: 1
• Values:
• 1: Yes.
• 0: No.
If canExecute If can Execute

• Default: 1
• Values:
• 1: Yes.
• 0: No.
If isRowSelected If isRowSelected

• Default: 1
• Values:
• 1: Yes.
• 0: No.
If existsParent If existsParent

• Default: 0
• Values:
• 1: Yes.
• 0: No.
Confirm If needs confirm before execute action button

• Default: 1
• Values:
• 1: Yes.
• 0: No.
Validate function / condition Function / condition to validate before execute (if false no execute)

Host condition (JS) Condition javascript

• Format: JS_EXPR
butt_message

• Format: SQLCOND_EXPR
butt_message_backup
Server condition (JS/SQL) JavaScript or SQL statement that determines the button

• Format: UELSQL_EXPR
butt_when_backup
Cache Cache SQL sentence condition to active button

• Default: 1
• Values:
• 1: Yes.
• 0: No.
Js function Function js to trap and modify vdata

Iterate cursor Cursor iteration, for each record it creates a button

• Format: SQLCOND_EXPR
butt_foreach_backup
SQL / XSQL sentence / Javascript SQL / XSQL sentence or Javascript

• Format: SQLCOND_EXPR
butt_stmt_backup
User created User that has created the object

• Default: USER
Date created Creation date

• Default: CURRENT
User updated User that has updated the image

• Default: USER
Date updated Updated date

• Default: CURRENT

Defining a button

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)

Action Id

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

Action constraint

Only actions of the current JRep Object can be executed.

Position

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

If row selected

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.

If parent

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.

Enable condition

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.

Cache

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

Script event (Deprecated)

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

Deprecated

This function is deprecated. Use dynamic fields or a UEL expression as default value on wic_jrep_form_action.

Dictionary
wic_jrep_box_celldata_action
Label Description
Box ID Box identifier
Action Id Action Identifier
Order Order
Activation condition If condition is true, menu will be activated

• Format: JS_EXPR
Label Label to show in menu
Icon Icon to display in menu
Confirm Indicates if confirmation is needed before the Execute Action button

• Default: 1
• Values:
• 1: Yes.
• 0: No.
Type Type of execution

• Default: 0
• Values:
• 0: Execute. Execute
• 1: Javascript . Javascript
Size form Size form

• Default: 0
• Values:
• 0: Auto.
• 1: Small.
• 2: Medium.
• 3: Large.
SQL / XSQL statement / JavaScript SQL / XSQL statement or JavaScript

• Format: SQLCOND_EXPR
User created User who created the object

• Default: USER
Date created Date created

• Default: CURRENT
User updated User who performed most recent modification

• Default: USER
Date updated Date updated

• Default: CURRENT

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

• Action Id
• Position

Action Id

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

Action constraint

Only actions of the current JRep Object can be executed.

Position

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

Diagram of use (according to trigger object)

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:

 Buttons wic_jrep_form_butt SQL Table Context Menu wic_jrep_box_celldata_action SQL Tree Context Menu wic_jrep_box_celldata_action Form JS Function executeFormAction Label action_label Icon action_icon Style action_style Can insert action_can_insert Can delete action_can_delete Can update action_can_update Can execute action_can_execute Enable expression action_enable_expression Before eval action_before_eval Form title action_form_title Form size action_form_size Form message action_form_message Confirm action_exec_confirm Execution type action_exec_type Execution statement action_exec_stmt Data update action_data_update Output type action_output_type Iteration action_iteration

2.4 Samples

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

2.4.1 Button to update the state of a transactional object (applying iteration statement)

Introduction

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:

Action Next action Description of action
1 0 Reset
1 2 Process
2 0 Reset
2 3 To revision
2 4 Accept
3 0 Reset
3 1 Deny
3 4 Accept
4 0 Reset

Defining a form action

The form action parameterization for that case consist on:

Column Value
Label ${description} Style Default Can Insert false Can Delete false Can Update false Can Execute false Execution type Server Side Update mode Refresh row Output type Auto Confirm false Execution statement Copy <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> Iteration statement Copy <select> <columns> action, next, description </columns> <from table='studio_actions_flow' /> <where> action =${action_state}
</where>
</select>
The columns not mentioned will be empty or generated automatically.

Defining action fields

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

Column Value
Position 0
Table virtualfoodmart
Column reason
Type CHAR
Size 10
Default #description
Entry true
Nullable false
Lettercase None
Condition disable action != 3 || next != 1

Defining a button

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

Column Value
Position 0
Action Id The Id of the action created before
If row selected true
Cache false

Execution

Once form action is defined and assigned to a button, when thew 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:

2.4.2 Context menu with action to delete a row of an SQL table

Introduction

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).

Defining a form action

The form action parameterization for that case consist on:

Column Value
Label ACTION_REMOVE_NODE
Style Default
Icon REMOVE
Can Insert false
Can Delete false
Can Update false
Can Execute false
Execution type Server Side
Update mode Refresh row
Output type Message
Confirm true
Execution statement
Copy
<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>
Message statement
Copy
<script>
var p_serial = Ax.context.data.serial_auto;

return 'Do you want to delete the row with serial auto = ' + p_serial + '?';
</script>
The columns not mentioned will be empty or generated automatically.

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

Column Value
Position 0
Action Id The Id of the action created before

Execution

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 setted 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: