Post-generating 3-level master-detail-detail screens

Question

Hi all,
for a consulting project, I had to create several three-level master-detail screens using JHeadstart. For the JHS demo app, this would mean for example that a location page contained a list of departments at the location and underneath it a list of employees working at the currently selected department.
From what I have learned so far using JHS, this is not supported by the wizards and should be done by post-generation changes. This forum has a few topics mentioning the problem and possible solutions, but most of the time just fragments of the complete solution/approach. As I had to create several of these 3-level detail screens, I tried to uniformly document them, providing the 7-step guide as outlined below. I only started working with JHS recently, so please let me know where I take a long way round or where my approach is not appropriate at all :o)
NOTE1: Terminology-wise, for the example given above, I will call the departments the 2nd level detail and employees the 3rd level detail, while locations are the first level masters. I hope this is not too confusing ;o)
NOTE2: the example code is not guaranteed to work with the JHSdemo. I just changed the names of variables and classes from my own application to the familiar entities of the demo.
STEP 1: Generate plain MD screens for the first and second level entities (table-form) using the JHS application generator and make sure all generated features you want in your page are OK. Afterwards, switch off the UIX generation in your application structure file. If you want multiple entities at the third detail level,
STEP 2: Add the functional contents of the generated 3rd level detail UIX page to the main master UIX page, right underneath the 2nd level detail-table but still inside the <header> entity of this 2nd level detail. (I'm not too sure whether this really matters, but at least the indentation looks nice). What I call "functional contents" is the <header> entity containing the 3rd level detail table.
STEP 3: Edit the java file of the 3rd level view object, adding a variable storing the identifier (primary key) of the currently selected 2nd level detail row. If you haven't used the java file before, generate it by doubleclicking the view object and checking the generate view object box in the Java screen.
private String $selectedDeptID;
public void setSelectedDeptID(String id) {
$selectedDeptID = id;
STEP 4: Edit the java file of your application module (in the model layer) and add a method for updating the view objects search queries like the example below:
public void updateEmployeeView(String deptID) {
// fetch the view object instance
EmployeeViewImpl view = (EmployeeViewImpl)this.getEmployeeView1();
// register the currently selected departments ID
view.setSelectedDeptID(deptID);
// re-execute the view objects query
view.executeQuery();
// reset the selected ID
view.setSelectedDeptID(null);
STEP 5: Create a java class for handling the event when a user selects a different 2nd level detail row.
package view;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;
import oracle.adf.controller.struts.actions.DataActionContext;
import oracle.adf.model.BindingContext;
import oracle.adf.model.bc4j.DCJboDataControl;
import oracle.adf.model.binding.DCDataControl;
import oracle.adf.model.binding.DCUtil;
import oracle.cabo.servlet.BajaContext;
import oracle.cabo.servlet.Page;
import oracle.cabo.servlet.event.EventResult;
import oracle.cabo.servlet.event.PageEvent;
import oracle.cabo.servlet.ui.data.PageEventFlattenedDataSet;
import oracle.cabo.ui.data.DataObject;
import oracle.cabo.ui.data.DataSet;
import oracle.cabo.ui.beans.table.SelectionUtils;
import oracle.jbo.ApplicationModule;
* USER-DEFINED EVENT-HANDLING CLASS
* this class is triggered after the user selects another row in the Department
* table/form in the Locations.uix screen. It derives the ID (pk) of the
* selected row and launches the AppModule method to update the view objects
* select queries with the selected DeptID.
public class RowSelector
* private variable holding the name of the DataControl module for this
* Application Module
private static final String DATACONTROLNAME = "AppModule" + "DataControl";
* private variable holding the name of the table/form object in the uix page
* from which we want to derive the selected row data.
private static final String TABLEFORMNAME = "DepartmentsView2";
* private variable holding the name of the form field holding the database
* ID (pk) of a row in the ${TABLEFORMNAME} table/form
private static final String IDFIELDNAME = "Dept_ID";
* This method fetches the ID of the user-selected row in the DepartmentsView2
* table/form in the Locations.uix form.
* Afterwards, it fires the ApplicationModule method for updating the view objects
public static EventResult doSelectionEvent(BajaContext bc, Page page, PageEvent event)
try {
// create a new FlattenedDataSet for the table name
DataSet tableInputs = new PageEventFlattenedDataSet(event, TABLEFORMNAME);
// fetch the UI table index from the DataSet (NOT the pk from the db)
int index = SelectionUtils.getSelectedIndex(tableInputs);
// fetch the DataObject representing all the input elements on the current table row.
DataObject row = tableInputs.getItem(index);
// fetch the value of the input field holding the ID (pk) of the selected department row
Object value = row.selectValue(null, IDFIELDNAME);
if (value != null) {
// tell the AppModule to update the appropriate view object(s)
getAppModuleImpl(bc.getServletRequest()).updateEmployeeView(value);
// quick and dirty exception handling. not too many exceptions possible due to
// hard-coded field/table/module names. anyway, taking no action at all is not
// that bad an option for a demo ;o)
} catch (Exception e)
e.printStackTrace();
return null;
* method for fetching the active Application Module
public static AppModuleImpl getAppModuleImpl(HttpServletRequest request)
BindingContext ctx = DCUtil.getBindingContext(request);
DCDataControl dc = ctx.findDataControl(DATACONTROLNAME);
AppModuleImpl service = (AppModuleImpl)dc.getDataProvider();
return service;
STEP 6: Override the executeQueryForCollection method in your view object java file to make sure it uses the selected 2nd level detail rows ID for the bound variable specifying the 3rd level select query. Otherwise, the select query for the 3rd level detail set appears to use the ID of the first 2nd level detail row selected for the currently selected 1st level master. In the example below, no other bound variables are used in the view object, otherwise, the indexing might have to be adjusted.
protected void executeQueryForCollection(Object qc, Object params[], int noUserParams) {
if ($selectedDeptID != null) params[0] = $uur;
super.executeQueryForCollection(qc, params, noUserParams);
STEP 7: In the Locations.uix page, set a primaryClientAction for the radio select input in the 2nd level detail screen. This action should fire an event (fe 'userChoseDepartment') and refresh the 3rd level detail tables using the partial refresh options in the primaryClientAction dialog window. Afterwards, add an event handler to the bottom of your Locations.uix page, linking the event specified before to the doSelectionEvent in the RowSelector class.
So, that's how it worked for me. I hope it does the same for you and please do post any comments or remarks if problems arise or simplifications are possible. The more remarks or bugs appear in the above code, the more the JHS team is hinted to enable auto-generated 3rd level detail screens :-D
Cheers,
benjamin

Answer 1

Benjamin,
Thank you for sharing your expreinces with us!
A few remarks:
1. With JHeadstart 10.1.2.1 you can generate unlimited master-detail levels in the same page when using UIX and table-layout for the detail groups This feature is implemented usin g UIX table detail disclosure: when you click on the "show" link in a row in of the level 2 detail table, you will see in the detail disclosure area the level 3 detail table.
There is a screen shot of this feature in the JHeadstart Developers Guide for 10.1.2.1, chapter 3, section "Creating Table Pages". You can now download the dev guide from the JHeadstart Product Center:
http://www.oracle.com/technology/consulting/9iservices/jheadstart.html
2. You have a lot of steps related to synchronizing the level 3 ViewObject with the level 2 ViewObject. You can leave all this work to ADF Business Components, by adding the l;evel 3 ViewObject as a nested usage to the level 2 ViewObject in your application module data model.
Ths would save you the work you aredoing in steps 3 to 6.
Steven Davelaar,
JHeadstart Team.