Metawidget generates widgets for domain object properties using a five-stage pipeline, specifically WidgetBuilders. There are WidgetBuilders for creating text boxes for string types, number inputs for number types, and so on. However whenever Metawidget encounters a property that its WidgetBuilders don't have a widget for, it creates a nested Metawidget and starts the pipeline process all over again:
The nested Metawidget shares the same pipeline objects as the outer Metawidget (i.e. same Inspectors, WidgetBuilders, etc). This makes nested Metawidgets very lightweight and performant. However it also means the Inspectors must be aware they can be used in multiple modes: in 'top-level' mode, and in 'nested mode'.
Inspectors can tell the difference because of the names array they're passed. In nested mode, the names array will be populated with a path of sub-properties to traverse. It's important the Inspectors honour this.
Back to our Java EE example. We'll expect two back-end REST schema calls: one for /rest/schema/person and one for /rest/schema/person/address. Clearly the back-end must also be expecting this and return different schemas for each (we recommend using client-side expiry headers on REST-based schemas: schemas don't change very often, and you can increase the performance of your UI by not making calls unnecessarily).
I've put together a complete example you can download here.
Of course, you may find multiple REST calls unacceptable for your use-case. Another approach would be to have your REST service return a JSON schema containing all your nested schemas at once. Then use metawidget.inspector.JsonSchemaInspector to inspect it. JsonSchemaInspector includes the ability to automatically traverse nested schemas, based on the names array.