BC4J supports two different styles of master-detail.
The first style is one where the user adds the master VO instance (usage) and the detail VO instance (usage) in the Application Module's Data Model. These two VO usages are related by a view link usage.
We refer to this style of master-detail as Data Model Master-Detail (or "DM MD" for short).
The main point of this style of master-detail is that the master and detail VOs are fixed. The view link between the two VO facilitates "data flow" eventing between the two VOs. When the currency moves on the master VO, an event causes the detail VO to be refreshed (executeQuery called with a new set of bind parameters). The detail VO now contains a new set of rows--rows that are related to the current master row.
Note that while the rows are refreshed, the VO stays stable. The user can bind UI objects to the detail VO. When the master VO's currency moves, the detail VO is refreshed with a new set of rows. The UI binding will be refreshed with these new rows.
The second style is one where the user takes a row from the master VO and calls an association/view-link accessor method on it. Typically, this accessor has the method name of the format:
get<association-or-view-link-end-name>()
For example, if you build a view link between DeptView and EmpView, the view link accessor on DeptView would be a method named "getEmpView()".
We refer to this style as row-level master-detail ("RL MD" for short).
Unlike the data model master-detail, RL MD does not require an Application Module or Data Model context. The entire master context is provided the the master row (hence the name "row-level"). RL MD allows the user to make an arbitrary number of association/view-link accessor invocations. Each invocation returns a RowSet that contains a set of detail rows that are related to *this* (calling) master row.
The following comparisons are noted between DM MD and RL MD: In DM MD, the VO is stable. The data rows in the VO are refreshed as the currency moves on the master VO. The data change, but the VO remains the same object. Thus, UI objects can bind themselves to this stable VO and respond to the refreshRange event, which is fired when the master VO's currency moves. Another way to characterize this is that DM MD is currency based (data flow) MD. DM MD is appropriate for a UI form where the master is shown in text boxes and detail shown in a grid control. As the master VO is traversed, the grid will be refreshed to show data related to the current master row.
In RL MD, the detail data rows are stable. As long as the association/view-link attribute value(s) in the master row remain unchanged, the detail data rows will not change. Change of currency will not affect the detail row set which is "attached" to the master row. Hence, RL MD is appropriate for a UI object like the tree control.
Another difference is this: for DM MD, the detail VO may have multiple master VO. For example, the EmpView VO may be a detail to the DeptView VO and the ProjectView VO. The Emp rows in EmpView includes only those Emp's whose Deptno and Projectid match the corresponding view link attributes in the DeptView <-> EmpView and ProjectView <-> EmpView view links. If DeptView shows Dept 10 and ProjectView shows Project 102 as the current row respectively, EmpView will show Emp's that belong to Dept 10 who work on Project 102.
Such multiple master situation does not apply to RL MD. The result of calling an association/view-link accessor is a RowSet whose data only meet the criteria set by the master row. I.e., the resulting RowSet exclusively belongs to one and only one view object (in fact, it belongs to one and only one view row instance!).
Thus, in the above example, one can get either Emp's for Dept 10 by calling the accessor from the DeptView row or Emp's for Project 102 by calling the accessor from the Project View row, but *not* Emp's that "belong" to the two master rows at the same time.
A common incorrect expectation is the following: user builds a DM MD. Then, he retrieves a row from the master VO of this data model. He calls an association/view-link accessor from this master row. A row set returns (this is RL MD). The user expects this row set to have originated from the detail VO in the data model. This is *not* the case. In all cases (whether the master row is from a master VO of a data model or not), the row set returning from a call to an accessor (RL MD) originates from an internal view object. This internal view object is created (by the framework) in the root application model.
The framework does not use any user created view object (including the ones in a data model) for accessor results (row sets). The main reason for this is that the VO used for association/view-link accessor need to be stable and should be unaffected by user's unrelated changes to the detail view object of the data model. For example, if we were to use the detail view object in the data model for accessor-result row sets, the accessor result will unintentionally be affected by changes like the following:
- The user could take the detail view object of the DM and set its where-clause with where-clause parameters. This is a perfrectly fine operation as long as the user supplies where-clause parameter values. However, if such a VO was used for accessor result, an error would ensue because the where-clause parameter values have not been supplied for the accessor result row set. (They were only supplied for the default row set of the detail view object.)
- The user could add (even during runtime) another master view object to this detail view object in the data model. In that case, the semantics of the accessor will be changed. Instead of an accessor returning "Emp's for this Dept," it may all of a sudden start returning "Emp's for this Dept and that Project."
- The user could remove the detail VO or the containing AM. In that case, all detail rows would become invalid, which is an unexpected side-effect.
- The framework needs to distinguish DM detail VO and RL detail VO for certain operations. For example, when you create a new row in a detail VO, the framework automatically populates the assocation/view-link attributes from the corresponding values of the master. In the DM case, it gets these values from the current row(s) of the master VO(s). In the RL case, it gets the values from the owning master row.
Because of reasons like the above, RL MD uses an internal view object
which is independent of application model data models.
2:27:27 PM 
|
