|
Difference Between View Link Attribute and View Link Instance in Data Model
When you define a view link, you permanently establish a relationship between a source and a target view object. Based on the view link properties, you can choose to expose the ability to traverse the view link via a view link accessor attribute in either the source view object, the target view object, or both.
As an example, imagine creating a view link named org.demo.DeptToEmpLink between an org.demo.DeptView component defined as:
SELECT DEPTNO, DNAME FROM DEPT
as the source, and an org.demo.EmpView component defined as:
SELECT EMPNO, ENAME,DEPTNO FROM EMP
as the target view object.
NOTE: If we are using view objects that are not based on underlying entity objects as we are for this quick example, before creating the view link between them we'll need to use the view object editor to mark the Deptno attribute as the "Key Attribute" for DeptView and similarly the Empno attribute as the Key Attribute for the Empview.
By default, we expose a RowIterator-valued view link accessor attribute on the source view object row, giving access to the collection of detail view object rows. On the View Link Properties panel in the view link editor, you can change the name of this view link accessor attribute. Let's say that we changed the default name of EmpView to have the name Employees instead for that attribute on the DeptView row. This means that in addition to being able to access a Number-valued Deptno attribute, and a String-valued Dname attribute in the DeptView result row, we can also access an attribute named Employees, and its value will be the collection of employee rows from the related EmpView in that department.
This "Employees" view link attribute is available anywhere you use DeptView rows.
So, for example, if you just add a single DeptView1 instance of org.demo.DeptView into your AM data model -- without adding any instance of org.demo.EmpView at all to the data model:
you can still write code like this in a client test program that accesses a row of this DeptView1 instance and then accesses its related collection of EmpView rows via the Employees view link accessor attribute on the DeptView row.
package org.demo;
import oracle.jbo.ApplicationModule;
import oracle.jbo.RowIterator;
import oracle.jbo.ViewObject;
import oracle.jbo.client.Configuration;
import org.demo.common.DeptViewRow;
import org.demo.common.EmpViewRow;
public class TestClient {
public static void main(String[] args) {
ApplicationModule am = Configuration.createRootApplicationModule("org.demo.TestModule",
"TestModuleLocal");
ViewObject vo = am.findViewObject("DeptView1");
DeptViewRow r = (DeptViewRow) vo.first();
RowIterator emps = r.getEmployees();
while (emps.hasNext()) {
EmpViewRow e = (EmpViewRow) emps.next();
System.out.println(e.getEname());
}
Configuration.releaseRootApplicationModule(am, true);
}
}
On the other hand, if you explicitly add an instance of EmpView to your AM data model, along with an instance of a view link, such that the AM datamodel looks like this:
- DeptView1
- EmpView1 (via DeptToEmpLink1)
Then this is actually representing three component instances:
- An instance of view object org.demo.DeptView named "DeptView1"
- An instance of view object org.demo.EmpView named "EmpView1"
- An instance of view link org.demo.DeptToEmpLink named "DeptToEmpLink1"
So I would expect to see three entries in the Application Module XML file reflecting this:
<ViewUsage
Name="DeptView1"
ViewObjectName="org.demo.DeptView" >
</ViewUsage>
<ViewUsage
Name="EmpView1"
ViewObjectName="org.demo.EmpView" >
</ViewUsage>
<ViewLinkUsage
Name="DeptToEmpLink1"
ViewLinkObjectName="org.demo.DeptToEmpLink"
SrcViewUsageName="org.demo.TestModule.DeptView1"
DstViewUsageName="org.demo.TestModule.EmpView1" >
</ViewLinkUsage>
Note that in the XML, the <ViewUsage> and <ViewLinkUsage> tags are not nested. It is a flat list of the instances that the AM data model contains. The "nesting", if you will, is contained in the attributes of the ViewLinkUsage metadata named SrcViewUsageName and DstViewUsageName, which the Data Model panel in the design time uses to visualize the view object instances as indented, the destination beneath its corresponding source.
Even in this latter data model setup, you can still access the related employee rows via the Employees view link accessor attribute, however by including the view link instance and target view object instance in the data model explicitly, you are asking the ADF Business Components framework to actively coordinate the detail view object for you as the current row in the master view object changes. This way, a client need only work directly with DeptView1 and EmpView1 view object instances, and the client always finds that EmpView1 shows the correct employees rows for the current row in DeptView1. With the previous example, you would need to programmatically access the view link accessor attribute to get your hands on the correlated collection of employee rows for a given department row that you have a reference to.
|
