completion of this stage you should be familiar with the following
names (reserved & user-defined)
Adding views to the application
Processing a row selected in a display table
data stored in the database
<Selected Row> (in Simple Table)
this stage you will add a new view to the application. In addition to
the initial view, used to enter requisitions, the new view is used by
managers to approve requisitions.
This stage’s modeling should
be performed in the Requisition Management system (5-6) project,
you imported at the end of the previous stage.
shall now add a second view to our application, Requisition
Approval. This view will be used by managers to view requisitions
entered by their employees and decide whether to approve them (or, in
the next stage, reject them).
Zoom to the root
model (Requisition Management
Select the Display/View
in the Palette and drop it next to the Open
Name it Requisition Approval.
model should now look similar to the following:
Requisition Approval view will contain a list of open
requisitions and buttons to Approve/Reject requisitions.
have already modeled the list of open requisitions in a previous
stage, so let's reuse it:
List from the Repository (or Outline)
and drop it in the Requisition
model should look similar to the following:
your work and view the application in the browser. Note the
additional tab Requisition Approval to the right of Open
you click Requisition Approval, you should see the following
(the Requisition List table is displayed but is still empty):
Requisition List is empty because we have not reused the
process which populates it originally (in the Open Requisitions
view) - Populate Open Requisitions List.
have a look at this process and recall what it does:
Populate Open Requisitions List process includes a Generate
Requisition List process which creates a Requisition List
data element populated with Requisitions from the database.
The generated Requisition List is then sent to populate the
table display through the Open Requisitions ancestor
is nearly identical to what we want to perform here, except that the
target table display is in the Requisition Approval view (the
new view we have just defined) rather than the Open Requisitions
view (the original view). So, we should create a new Populate
Requisition Approval List process in the current view, reusing
the Generate Requisition List process.
Zoom into Requisition Approval.
in the palette and drop it in Requisition
Name it Populate Requisition Approval
To reuse Generate
Requisition List, drag it from the outline
and drop it into Populate
Requisition Approval List.
Right-click on the Populate
Requisition Approval List element, select Add
Ancestor Reference from the menu, and select
Use the Flow
tool to link the exit of Generate
Requisition List to Requisition
your work and view the application in the browser.
you click on the Requisition Approval tab, you should see the
can verify that the requisition list appears in both views and
updated when a new requisition is entered in the Open Requisitions
Requisition Approval view should provide a manager with the
ability to select a row in the table and mark it Approved (or
start with creating the button itself. To keep this view consistent
with the Open Requisitions view, place the button above the
in the palette and drop it in Requisition
Approval (above the Requisition
Name it Approve Requisition.
Requisition Approval model should look similar to the
let’s model the button logic, which should consist of the
Retrieving the selected row from the table
Status field value for the row to Approved
Updating the corresponding record in the database
Requisition List table to display the updated record
retrieve the selected row from a table display, we first need to
include a reference to the display.
Zoom into Approve
Right-click on Approve
Requisition, select Add
Ancestor Reference from the menu, and select,
Approve Requisition model should look similar to the
<Selected Row> data
element is included by default in any display element based on the
Simple Table (or
Whenever the user clicks a row in the table (at runtime), the
element will contain the data in that row.
The <Selected Row>
element supports any row structure defined in it's parent model (the
table). This is possible as it is based on the
<Selected Row> element returns the selected row as a
Requisition data structure. We should now create a process
which changes the Status of the selected requisition to
in the palette and drop it next to the Requisition
Approval ancestor reference.
Name it Change Requisition Status.
Change Requisition Status process we are creating should
receive the selected Requisition as input:
Select the Trigger
in the palette and drop it on the frame of Change
Approval/Requisition List/<Selected Row> to
the trigger just added to Change
a moment we will add additional slots, so it would be a good idea to
name the slot we have just created so that its purpose (and content)
is clear to anyone looking at the model.
Select the trigger we have just added and press
In the edit box that appears, enter Original
Requisition as the name of the trigger.
additional input to Change Requisition Status should be the
new value to set Status to:
in the palette and drop it next to the new trigger (outside Change
Requisition Status). Name it Approved.
Add another Trigger
to Change Requisition Status.
Select it and press [F2]
to name it Updated Status.
linking the “Approved”
constant to the Change Requisition
Status/Updated Status trigger.
the process should output the updated Requisition:
Add an Exit
to the frame of Change Requisition
Status. Select it and press [F2]
to name it Updated Requisition.
let’s drill into Change Requisition Status and model the
update of the Status field of Requisition.
Zoom into Change
Drag the Requisition
database record into Change
linking the Original Requisition
trigger to the Requisition
linking the Updated
Status trigger to the Requisition/Status
linking the Requisition
data structure to the Updated
Change Requisition Status model should look similar to the
Updated Requisition exit slot returns an approved requisition,
which should be updated in the database. We shall use the Update
template for this purpose.
Zoom out to the Approve
Requisition button model.
Select the Database/Update
and place it next to the Change
Requisition Status process.
linking the Change Requisition
Status/Updated Requisition exit to Update/<Record>
have to make sure the table is refreshed on screen if Update was
successful, so that the display is kept synchronized with the
database. On a successful update, the Update process will exit
through its <Updated> exit:
Drop a Basic/Action
template next to Update.
Name it Refresh Requisition List.
We’re creating a new process
model, with an identical name to an existing process (there’s a
similar Refresh Requisition List process in Submit
Requisition). This is possible when the 2 models are in different
“packages” in the repository. Giving a new model the name
of an existing model in the same package is prohibited.
Right-click Refresh Requisition List and
open the Add Element sub
menu to select the Control trigger.
linking the Update/<Updated>
exit to the Refresh Requisition
lastly, reuse the Populate Requisition Approval List process
we created in the beginning of this stage:
Drag the Populate
Requisition Approval List process from the outline
into the Refresh Requisition List
Click on the Requisition
Click on the Approve
Requisition button before selecting a requisition.
should occur, since no requisition is selected.
Click on one of the new
requisitions in the list.
selected row is signified by a slightly darker background color, as
in the following screenshot (3rd row):
Click on the Approve
table should be refreshed and the requisition selected should change
status to Approved, as in the following screenshot:
the sample project Tutorial 6-7 and use it as the basis for
the next stage of the tutorial.
For a reminder on how to import a
sample project, see the Importing a Sample Project section at
the end of Stage 2.
sample project contains all the functionality modeled thus far.
may now proceed to Stage 7,
in which we shall model similar buttons to the Approve
Requisition button modeled in this stage, by re-factoring (change)
parts of the modeling and re-using it for canceling and rejecting
Click here to open the live project in a
For best results, use the Firefox browser..