Frequently Asked Questions - Motivation
If you're asking yourself, or Googling for, the following motivating factors then Metawidget may be for you:
"I want a lightweight UI generator I can just throw an object at"
Metawidget works as a lightweight, no fuss solution out-of-the-box. You can render a JSON object to the UI in just 3 lines.
"I need a UI generator I can customize"
Most UI generation scenarios involve a lot of things that are generally the same, with a few that are specific to your app.
For example, for an intranet app you may be fine with Metawidget's out-of-the-box UI rendering, but have exacting requirements around the way metadata gets sourced. Metawidet's pluggable Inspector architecture allows you to swap out the bits you need to change, whilst keeping the rest of the UI generation pipeline the same.
Alternatively, for a consumer app you may have simple metadata requirements (say, just a POJO) but exacting requirements around how the UI gets rendered. Metawidget's pluggable Layout architecture allows you to reuse the metadata parsing whilst swapping in a custom layout.
As a final example, if your app uses third-party widget libraries you can swap in support for specific widgets and custom datatypes, whilst leaving the rest of the pipeline at its default settings.
"I want a UI generator that separates inspection of metadata from generation of the UI. So I can use other sources of metadata like REST endpoints and SOAP WSDLs"
Metawidget's pluggable Inspector architecture separates inspection from generation, so that it can be performed across different tiers of your application - or even remotely using technologies such as REST. Inspectors are flexible enough to support a wide variety of metadata including: Java objects; XML files; SQL schemas; Business Rule Engines and REST endpoints.
"I want a UI generator that can build a rich meta-database describing entities and their relationships - a context belonging to each screen"
Metawidget's pluggable Inspectors can extract metadata from a broad range of sources, which its CompositeInspector can then combine together. Next, its InspectionResultProcessors can process this overall metadata in the context of each screen. Finally, its WidgetBuilders, WidgetProcessors and Layouts iterate over this metadata to generate the UI.
This approach ensures metadata inspection is kept orthogonal to metadata processing, which in turn is kept orthogonal to widget choosing, which in turn is kept orthogonal to layout style.
Such separation maximizes reuse. For example, you don't have to redefine how to construct a div-based layout for both the summary and the detail screens of your app - you only have to hook in a different InspectionResultProcessor to prepare the metadata differently (such as limiting the number of fields for the summary screen).
