Connect as reference: Implementing a reference look-up
The gadget spec URL could not be found
In this section, we will implement a look-up for category code in the "ProductOrders" data model. Follow the directions given below.
Select the "CategoryDescription" public cell.
Click on the "Connect" icon.
Select "Reference Cell" option from the list displayed.
"Reference Cell Connection Wizard" will be displayed.
Select "Category" from the list of models.
Select "CategoryDescription" from the list of display cells.
Click on the "Create" button.
A connection will be established between "ProductOrders" and "Category" via "CategoryDescription" public cell.
Click on the "OK" button.
A reference look-up relationship will be created and a list box will be available for the "CategoryDescription" public cell.
We have successfully created a reference look-up for the "CategoryDescription"
public cell in the "ProductOrders" data model. How can we confirm it?
Implement and test if it works?
Test as you go!
Continue reading to find out how.
Test As You Go! How?
Test-as-you-go feature allows you to test a functionality (your business rules) without having to implement it. Let's learn how to use this feature by testing the reference look-up that we just created.
Open the "Category" data model.
Enter some test values for the public cells "CategoryCode" and "CategoryDescription". For example,
"MT02" in the "CategoryCode" public cell.
"Men's Long Sleeve Tees" in the "CategoryDescription" public cell.
Click on the "Instance" icon to create more test data. You can also use the "Insert instance" option to create a new instance.
What is an Instance?
Instance in a model can be thought as a record in a database table as or as an object in an object oriented method.
Open the "ProductOrders" data model. A list box must be available for the "CategoryDescription" public cell with the test values entered.
What is "SheetID"?
All of us are familiar with the concept of primary key and foreign key. The primary key is used to uniquely identify a record in a database table; in some cases, a system generated global unique identifier (GUID) is also used as primary key. Foreign keys are used to create a link between two tables i.e. cross-reference tables.
OrangeScape generates an internal reference key, refered to as "SheetID", for every instance (record) created in any data model. It uses "SheetID" to uniquely identify an instance. Also, when we create a relationship between two models using the connect option, it stores the Sheet ID in the public cell that was used to create the connection.
What purpose does storing "SheetID" internally serve?
Auto-refactoring across the layers! Simply put, changes in model names
and parameters are automatically reflected across all layers.
An example? Let's check what value is stored in the "Category_code" public cell in "ProductDetails" data model.
Select the "CategoryCode" public cell.
It can be observed that the formula bar doesn't display the category code "MT01" as displayed in the public cell "CategoryCode".
The value in formula bar will match the value in active instance tab at the bottom of the page. This value is nothing but the "SheetName". This is a system parameter (public cell) similar to "SheetID". By default, "SheetID" is set as the value for "SheetName". This can be changed to any value.
Whenever a connection is established, OrangeScape stores the "SheetID" internally for that public cell; the value displayed is that of the display cell selected.
In this case, we selected "CategoryCode" as the display cell. Hence, "MT01" is displayed in the public cell.