Tersus: Table Wizard [version 2.1.8]

Table Wizard [version 2.1.8]Date: Jul 24, 2012Tags:Table WizardThe usage of the Table Wizard to quickly create a table-centric application was demonstrated in the Shopping List tutorial, covering:

Creating a new table

Modifying the created table to automatically refresh upon any update

Adding action buttons to table rows

Modifying the table to dynamically hide some fields

Managing valid values of fields

Filtering

This tutorial further demonstrates the usage of the Table Wizard to create linked tables - several tables where the selection of a row in one table changes the content displayed in another table. A typical case is a primary table with secondary details table(s) below it, where the details table(s) display additional information related to the row selected in the primary table.We will demonstrate this functionality by re-modeling parts of the Tersus Step By Step Tutorial. Creating a Requisition Table

Create a new Tersus project 'Table Wizard Demo':

Project name: Table Wizard Demo
Template: Legacy Navigation [as in stage 1 of the step by step tutorial]
Theme: Default

Create a view for entering new requisitions [compare with the last part of stage 9 of the step by step tutorial]:

Create a perspective Employee (select 'System' from the 'Basic' section of the palette).
Zoom into 'Employee' and create a view Open Requisitions (select 'View' from the 'Display' section of the palette).

Start the table creation wizard by selecting 'Table Wizard' from the 'Display' section of the palette and clicking inside Open Requisitions:

Set 'Display Name' to Requisitions;
Add a field Id (Number) [primary key of type 'Model Generated'];
Add a field Description (Text);
Add a field Date (Date);
Add a field Status (Text); Specify New, Approved, Rejected, Fulfilled as valid values (don't forget the commas between the values);
Add a field Urgency (Text); Specify Regular, Urgent as valid values;
Click 'Advanced >>'. Uncheck 'Show paging header group';
Press 'Finish'.
Optional: In Requisitions, zoom into Header Row/Action Header Group/New/Enter Details/Footer, and rename the Save button to Submit Requisition (be careful to uncheck the 'Keep package name equal to model name' before typing the new name - if the package name is changed, you will no longer be able to apply the Table Wizard to the requisitions table to introduce changes).

Save the model and launch the application (

). You can already create requisitions [corresponding to the functionality at the last part of stage 5 of the step by step tutorial].

Note that since Id is the primary key of the Requisitions table, once you create a requisition, you cannot change its Id field (only update the other details of the requisition or delete it altogether).

Adding the Purchaser Perspective

The following corresponds more or less to stage 11 of the step by step tutorial:

Zoom up to the top level model and create a second perspective Purchaser.
In this perspective, create a view Issue Purchase Orders.
In this view we will display a subset of the records stored in the Requisitions table:
1. Start the table creation wizard by selecting 'Table Wizard' and clicking inside Issue Purchase Orders:
1. Set 'Display Name' to Approved Requisitions;
2. Press 'Import Fields' to import the structure of the Requisitions table:
  - Click inside the Data Source box, select jdbc/Main, and press 'OK';
  - Click inside the Table Name box, select REQUISITIONS, and press 'OK';
  - Press 'Select All' and then 'OK';
  - Press 'Finish' to return to the wizard with a list of all the imported fields.
3. Press 'Select All' (the new table will display all fields of the Requisitions table);
4. Uncheck 'Show paging header group' and 'Show action header group' [this will be a read-only table];
5. Press 'Finish'.
If you save the model and re-launch the application (), you will see that your application now has two perspectives (Employee and Purchaser). Both display the same content, but requisitions cannot be created from the second perspective:
To restrict the display to approved requisitions only, we will have to make a small change to one of the processes created by the Table Wizard [compare with the last part of stage 11 of the step by step tutorial]:
1. In Approved Requisitions, zoom into Init/Init Display/Go to First Page/Populate Table/Create Parameters/Extract Filters/Extract Match Constraints (Populate Table is the process used each time we refresh the table display, and Extract Match Constraints is a sub-process creating constraints on the retrieved set of records).
2. Change the trigger of Extract Match Constraints to non-mandatory.
3. Drag into the process the Approved constant from the package Employee/Open Requisitions/Requisitions/Wizard/Database/Status in the Repository.
4. Create a flow from the "Approved" constant to the Status field of Database Record (implying we want to retrieve only requisitions with status "Approved"):

Creating a Linked Table

The following corresponds more or less to the first parts of stage 14 of the step by step tutorial:

Zoom up to the Issue Purchase Orders view and create a second table using the Table Wizard:
1. Set 'Display Name' to Purchase Orders;
2. Add a field Requisition Id (Number); Specify Table=REQUISITIONS, Column=Id as valid values;
3. Add a field Id (Number) [primary key of type 'Model Generated'];
4. Add a field Details (Text);
5. Add a field Supplier (Text);
6. Add a field Date (Date);
7. Add a field Price (Number);
8. Uncheck 'Show paging header group' and 'Show action header group' [since we'll have a special button to create orders, Purchase Orders will be a read-only table];
9. Press 'Finish'.
To link the Purchase Orders table to the Approved Requisitions, we would like the Purchase Orders table to display only orders related to the requisition selected in the Approved Requisitions table:
1. In Purchase Orders, zoom into Init/Init Display/Go to First Page/Populate Table/Create Parameters/Extract Filters/Extract Match Constraints.
2. Change the trigger of Extract Match Constraints to non-mandatory.
3. Add to Extract Match Constraints an ancestor reference to the Issue Purchase Orders view (we need a reference to this model, because it is the common parent of both Approved Requisitions and Purchase Orders).
4. Create a flow from Issue Purchase Orders/Approved Requisitions/Approved Requisitions/<Selected Row>/<Primary Key>/ID to Database Record/Requisition Id (we retrieve only orders whose Requisition Id is the Id of the selected requisition in the Approved Requisitions table):
To refresh the display of the Purchase Orders table whenever a requisition is selected in the Approved Requisitions table:
1. In Approved Requisitions, zoom into Approved Requisitions/Table Row.
2. Add to Table Row an <On Click> action and zoom into it.
3. Add to <On Click> an ancestor reference to the Issue Purchase Orders view.
4. Add to <On Click> 'Refresh' from the 'Display Actions' section of the palette.
5. Create a flow from Issue Purchase Orders/Purchase Orders to the trigger of Refresh. Thus, whenever a row is clicked and selected, the Purchase Orders table is refreshed.
6. The 'Refresh' button of Purchase Orders is now redundant, and we can refrain from creating and displaying it:
  - In Purchase Order, zoom into Init/Init Display/Init Display by Configuration/Init Header Row by Configuration/Init Paging Header and Refresh Groups by Configuration.
  - Delete the flow from the exit of Create Refresh Group.
Save the model, stop the application (), and re-launch it (). Stopping the application is required to make Tersus create the new table in the database when restarting the application.
Note that at this stage we cannot see any order in the Purchase Orders table, because we haven't created orders yet. The modeling we did in this stage will only become relevant once there are records in the Purchase Orders table, as explained below.

Creating OrdersThe following corresponds to the last part of stage 12 of the step by step tutorial and the first part of stage 13:

In Approved Requisitions, zoom into Header Row.
Add a button Order ('Button' from the 'Display' section of the palette).
Zoom into Order and model the order creation by reusing the order creation dialog which was automatically created by the Table Wizard as part of the model of the Purchase Orders table:
1. Add to the Order button an ancestor reference to the Issue Purchase Orders view.
2. Also add to Order an action with a single trigger and a single exit. Name it Create Default Order Details.
3. Create a flow from Issue Purchase Orders/Approved Requisitions/Approved Requisitions/<Selected Row> to the trigger of Default Order Details.
4. In the Repository, go to the package Purchaser/Issue Purchase Orders/Purchase Orders/Table/Action Header Group/New. Drag from there the Enter Details model (into the Order button).
5. Add to Enter Details a non-mandatory trigger Default Order Details [we are modifying the model create by the Table Wizard, but since the trigger is not mandatory, the modification will not affect the existing usages of Enter Details].
6. Create a flow from the exit of Default Order Details to the newly created trigger of Enter Details:
The modeling of the Create Default Order Details process is very simple:

Note: Database Record is from the package Purchaser/Issue Purchase Orders/Purchase Orders/Wizard/Database.
To complete the modeling, we still have to use the default record created by this process in Enter Details:
1. Zoom into Enter Details.
2. Copy the Default Order Details trigger (right click the trigger and select Copy), and paste it to the Init sub-process of Enter Details (right click Init and select Paste (Reuse)).
3. Create a flow from the Default Order Details trigger of Enter Details to the corresponding trigger of Init:
4. Zoom into Init.
5. Drag into Init the Convert Record to Grid model from the package Purchaser/Issue Purchase Orders/Purchase Orders/Wizard/Transformations.
6. Create a flow from the trigger of Init to the trigger of Convert Record to Grid.
7. Create a flow from the exit of Convert Record to Grid to Enter Details/Details Grid.
8. Since the button Order uses the selected requisition to initialize the Requisition Id and Details fields of the created purchase order, it makes sense to prevent the change of at least the Requisition Id field (the user may, however, edit the Details). To set the field to be read only, create a flow from the exit of Convert Record to Grid to a Boolean constant "Yes", and another flow from "Yes" to Enter Details/Details Grid/Requisition Id Row/Requisition Id/<Read Only>.
9. The modeling of Init now looks like this:
If you save the model and launch the application, you will be able to select a requisition, press the Order button and create a purchase order for the selected requisition:

Download Model: Final Model (version 2.1.9).
See Also:

To use the full functionality of this web site, JavaScript needs to be turned on.

For best results, use the Firefox browser..

Loading ...