About the Original Author

Recent articles by this author

The Domino documentation says the following about subforms: A subform is a collection of form elements that are stored as a single object. Subforms can contain the same elements as regular forms. Subforms save redesign time. When you change a field on a subform, every form that uses the subform ...

It's a very common design practice to have one section of your user interface be visible, or invisible, based on the values in another section. This helps minimize confusion of what should and should not be entered. Lets example a very simple, but representative, use case of this. We have a combo ...

Client side Javascript frequently makes use of IDs that have been assigned to controls in order to encode client side logic. Take the simple case where you have a combo box above an edit box. When some values in the combo box are selected, the edit box should be visible, and when others are ...

It's a very common design practice to have one section of your user interface be visible, or invisible, based on the values in another section. This helps minimize confusion of what should and should not be entered. It is also useful in a workflow application for showing or hidding sections ...

Just as companies may have applications based on different technologies, it is equally common for data to be stored in different repositories. You can easily direct XPage elements to surface data from different Notes applications. It turns out not to be much harder to surface data from different ...

The Domino documentation says the following about subforms: A subform is a collection of form elements that are stored as a single object. Subforms can contain the same elements as regular forms. Subforms save redesign time. When you change a field on a subform, every form that uses the subform updates.

However, with XPages, it also says: When using a subform on an XPage, you may find that you cannot "data bind" to fields in a subform that is included on that XPage. ... In order to bind to the field, you currently must type the name of the subform manually in the Data Binding field.

What's happening here is that when you design a form for use in the rich client you are designing a user interface. Underneath there can be (and often are) any number of fields. But just the ones defined in the form are displayed to the user. If you switch the document's form to another one, that gives a different window into what is displayed. Adding a subform adds those additional "windows" to the underlying data for being viewed.
In the case of an XPage, it is different. The layout you make on the XPage is the definition of the UI. A form is used purely as a data schema. Since a document can actually contain any field, you can actually surface anything you like in your XPage UI. But to make it easier for the developer, a form can be referenced to ease the data binding experience (and also provide some validation). You can always bypass this and bind any data elements you wish. We're going to look at that a little closer. The Form
Lets say we have a database, and in the database we define a subform like this:

and say we used that on a form like this:

To use this on an XPage we can define a data source tied to that form:
However, as documented, this only brings in the fields in the form, not the subform:

Fortunately, the lack of the sub forms appearing is only a problem in the designer user interface. When the form is accessed the fields in the subform are actually there and can be accessed in the same way as the fields of the form.
When you drag from the data palette to the form, you get an edit box for each data item. This is bound to the field in the data source. For example, if we drag FormFieldA form the above example, we get an edit box with a data binding that looks like this:
It's possible to copy and paste that edit box into a new cell in the table, and then edit how the data source is bound, and manually enter in the subform field's name. So for the first field in the subform this would look like this:

And when it's brought up in the UI you can see that all fields, form and subform, are rendered:

Note that this method can be used for any field in a document, not just ones that appear on subforms. You can bind to arbitrary or ad-hoc fields using this mechanism too.