Sub Forms

OpenOffice.org Developer's Guide

Forms

< Previous Section

Next Section >

• Models and Views

• The Model-View Paradigm
• Models and Views for Form Controls
• Model-View Interaction
• Form Layer Views

• Form Elements in the Document Model

• A Hierarchy of Models

• FormComponent Service
• FormComponents Service
• Logical Forms
• Forms Container
• Form Control Models

• Control Models and Shapes

• Form Components

• Control Models
• Forms
• HTML Forms

• Data Awareness

• Forms

• Forms as Row Sets
• Loadable Forms
• Sub Forms
• Filtering and Sorting
• Parameters

• Data Aware Controls

• Control Models as Bound Components
• Committing Controls

• External Value Suppliers

• Value Bindings

• Form Controls accepting Value Bindings

• External List Sources

• Validation

• Validation in OpenOffice.org
• Validation and Bindings

• Scripting and Events
• Common Tasks

• Initializing Bound Controls
• Automatic Key Generation
• Data Validation
• Programmatic Assignment of Scripts to Events

< Previous Page

Next Page >

A powerful feature of Apache OpenOffice are sub forms. This does not mean that complete form documents are embedded into other form documents, instead sub form relationships are realized by nesting logical forms in the form component hierarchy.

When a form notices that its parent is not the forms container when it is loaded and in live mode, but is dependent on another form, it no longer acts as a top-level form. Whenever the parent or master form moves to another record, the content of the sub or detail form is re-fetched. This way, the content of the sub form is made dependent on the actual value of one or more fields of the parent form.

Typical use for a relationship are tables that are linked through key columns, usually in a 1:n relationship. You use a master form to travel through all records of the table on the 1 side of the relationship, and a detail form that shows the records of the table on the n side of the relationship where the foreign key matches the primary key of the master table.

To create nested forms at runtime, use the following example:

  // retrieve or create the master form
  m_xMasterForm = ....
 
  // bind it to the salesman table
  m_xMasterForm.setPropertyValue("DataSourceName", m_aParameters.sDataSourceName);
  m_xMasterForm.setPropertyValue("CommandType", new Integer(CommandType.TABLE));
  m_xMasterForm.setPropertyValue("Command", "SALESMAN");
 
  // create the details form
  XIndexContainer xSalesForm = m_aDocument.createSubForm(m_xMasterForm, "Sales");
  XPropertySet xSalesFormProps = (XPropertySet)UnoRuntime.queryInterface(
      XPropertySet.class, xSalesForm);
 
  // bind it to the all those sales belonging to a variable salesmen
  xSalesFormProps.setPropertyValue("DataSourceName", m_aParameters.sDataSourceName);
  xSalesFormProps.setPropertyValue("CommandType", new Integer( CommandType.COMMAND));
  xSalesFormProps.setPropertyValue("Command",
      "SELECT * FROM SALES AS SALES WHERE SALES.SNR = :salesman");
 
  // the master-details connection
  String[] aMasterFields = new String[] {"SNR"}; // the field in the master form
  String[] aDetailFields = new String[] {"salesman"}; // the name in the detail form
  xSalesFormProps.setPropertyValue("MasterFields", aMasterFields);
  xSalesFormProps.setPropertyValue("DetailFields", aDetailFields);

The code snippet works on the following table structure:

Sales tables

The code is straightforward, except for setting up the connection between the two forms. The master form is bound to SALESMEN, and the detail form is bound to a statement that selects all fields from SALES, filtered for records where the foreign key, SALES.SNR, equals a parameter named salesman.

As soon as the MasterFields and DetailFields properties are set, the two forms are connected. Every time the cursor in the master form moves, the detail form reloads after filling the salesman parameter with the actual value of the master forms SNR column.

Content on this page is licensed under the Public Documentation License (PDL).