Create HTML forms from JavaScript objects: Metawidget 4.1

Version 4.1 of Metawidget, the library for creating HTML forms from JavaScript objects is now available!

This release was focused on:

• JQuery Mobile layout improvements (suppressDivAroundLabel, suppressDivAroundWidget)
• Improved support for JQuery Mobile overridden widgets
• Top-level styleClass (JavaScript Metawidget)
• Fix recursive save on Web Components
• Bootstrap improvements (wrapInsideLabels, wrapWithExtraDiv)
• Support table footers in HtmlWidgetBuilder (JavaScript Metawidget)
• Windows Mobile Internet Explorer compatibility
• Bug fixes, documentation and unit tests

As always, the best place to start is the Reference Documentation:

http://metawidget.org/doc/reference/en/pdf/metawidget.pdf
Your continued feedback is invaluable to us. Please download it and let us know what you think.

JavaScript Form Generator: from Java EE to Bootstrap 3 (Part 2)

I was recently asked to extend one of my previous blog posts with the ability to inspect nested, annotation-based, Java EE back-end domain objects using a JavaScript, Bootstrap 3 front-end.

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.