One of the design goals for Metawidget is separating the 'gathering of metadata' from the 'application of metadata to construct user interfaces'. So far, I've settled on two broad abstractions: Inspectors and WidgetBuilders.
The Inspectors will implement some common interface and allow a uniform way to inspect a variety of back-ends (JavaBeans, XML configuration files, annotated POJOs, etc.) to look for metadata. The WidgetBuilders will be tailored to each platform (FacesWidgetBuilder, SwingWidgetBuilder, etc.) and construct a native UI. Metawidget itself will sit in the middle, co-ordinating the interaction between the Inspectors and the WidgetBuilders.
From there, something became apparent pretty quickly.
Originally, I was going to have the Inspectors mine as much as metadata as they could from the back-end, then pass the result to the WidgetBuilder for construction. This certainly has an elegance about it.
However, in practice the developer must be able to override certain portions of the finished interface, either to insert new components or hide existing ones. In the latter case, the developer may choose to hide a portion of the interface (intending, perhaps, to move it to a separate screen) that cuts out a whole branch of the Inspector's metadata.
If the Inspectors have already inspected that metadata, this could be very inefficient. Furthermore, unless the Inspectors are told where to stop, how do they know how far to go? Should they traverse every possible piece of metadata they find? How do they know what their WidgetBuilder will ultimately need? It may depend which UI screen the WidgetBuilder is serving?
It seems the best way to solve this is to flip things on their head: have the WidgetBuilders drive the Inspectors. The user will instruct the WidgetBuilder what aspect they want to render, the WidgetBuilder will see what's involved (minus those parts of the UI the user has opted to override), and will then proceed to ask the Inspectors (via Metawidget) for metadata. Based on what they get back, the WidgetBuilders may later ask for further metadata.
This 'feedback cycle' is perhaps a little less intuitive than the input/process/output approach, but I think works much neater in practice.