Create custom transactions

A transaction is a group of SQL statements whose effects are logically connected. Anything from simple queries to inserting, and deleting operations can be considered a transaction, as well as more complex groups of several statements which accomplish a specific task.

A dispatcher is a component of the Transaction Engine which contains all the transactions on a page and handles all interactions between that page and the transactions: executes the transactions, feeds the recordsets generated by the transactions to the page, displays the transaction's error messages, etc.

A recordset is the result of executing an SQL query. It is composed of multiple rows, each row having multiple columns. The columns presented in the query result depend on the column list declared in the query (they can belong to different tables). The number of rows and their order depend on the query conditions (WHERE, GROUP BY, HAVING, ORDER). The recordset acts as a source of dynamic data in web applications.

A query is a SQL command that will extract information from the tables of a database. Essentially, a query is a request for information from your database.

The InterAKT Dynamic Data tool is a replacement for the standard dynamic data dialog. It is used in the MX Kollection 3, to provide a unified way of building mark-ups, or place holders. These are recordset fields, server or session variables, and other types of dynamic data that are replaced at runtime by their corresponding values

Create custom transactions

A Custom Transaction can have as main operation any SQL statement or no SQL statement at all, just a set of instructions. It is generally used to execute more complex INSERT/UPDATE/DELETE statements.
Let's build a custom transaction that executes an insert statement and then redirects to another page using some of the submitted values.

We'll start the page by including the Transaction Engine classes:

// Load the tNG classes
require_once('includes/tng/tNG.inc.php');

And then create the unique page dispatcher object:

// Make a transaction dispatcher instance
$tNGs = new tNG_dispatcher("");

The standard connection is transformed into a Transaction Engine connection and made available through a variable:

// Make unified connection variable
$conn_localhost = new tNG_connection($localhost, $database_localhost);

Next comes the code for defining the custom triggers, but they will be displayed in detail later.
After this, the actual Custom Transaction is instantiated and the custom triggers are added to the new Transaction:

// make an instance of the transaction object
$customTransaction1 = new tNG_custom($conn_test);
$tNGs->addTransaction($customTransaction1);

// register triggers
$customTransaction1->registerTrigger("STARTER", "Trigger_Default_Starter", 1, "POST", "MM_custom");
$customTransaction1->registerTrigger("BEFORE", "TriggerBEFORE_AddField1", 1);
$customTransaction1->registerTrigger("BEFORE", "Trigger_Default_Validate", 1, $Validate1);
$customTransaction1->registerConditionalTrigger(@$_POST['cb'] == 1, "END", "TriggerEND_Redirect1", 98);
$customTransaction1->registerTrigger("END", "TriggerEND_Redirect1", 99);

The above code is similar to that of a classic insert. What comes next is particular for the custom transaction: You can set the actual SQL string to be executed:

// set transaction SQL
$customTransaction1->setSQL("INSERT INTO users (UserID, Forename,
Surname, Email, Level) VALUES ({UserID}, {Forename}, {Surname},{Email}, {Level})");

The above SQL statement is different from a classic SQL insert statement because it doesn't contain values to be inserted, but placeholders, or mark-up language, such as {FieldVariable}. They are replaced with their corresponding values at runtime because the Transaction has columns registered to it and knows how to get the values:

$customTransaction1->addColumn("Surname", "STRING_TYPE", "POST", "Surname", "");
$customTransaction1->addColumn("Email", "STRING_TYPE", "POST", "Email", "default@default.com");
$customTransaction1->addColumn("Level", "NUMERIC_TYPE", "POST", "Level", 2);
$customTransaction1->addColumn("UserID", "STRING_TYPE", "POST", "UserID", "");

Finally, execute the transaction and get the result Recordset:

$tNGs->executeTransactions();
$rsCustom = $tNGs->getRecordset("custom");
$row_rsCustom = mysql_fetch_assoc($rsCustom);
$totalRows_rsCustom = mysql_num_rows($rsCustom);

As you can see in the above code, the getRecordset() method of the dispatcher doesn't receive a table name as parameter (like in the insert/update transactions), but a default string (“custom”).