I just had an interesting exchange with the guys from the OpenXava project. We discussed differences in our two approaches, as well as those of other UI generation projects, and what it would take to unify them all under a JSR one day. I think we're a long way from that day, primarily because UI generation isn't particularly 'mainstream' yet (at least, not in the sense of ORM). Still, it's often said in physics that even though we don't know what the Unified Theory is, we know something about what features it must have.
Can we say something similar about UI generation? I'll list here all those features I think are being explored, either by Metawidget, OpenXava or one of the other projects, and see if we can update this page over the years to form consensus.
Static or Runtime
Should the generation happen statically or at runtime? If runtime, how do you allow customisation? If statically, how do you allow re-running the generation when the domain model changes (without losing any customisations)?
Static: n/a
Runtime: Metawidget, Naked Objects, Woko
Modeling Language
Should the generator have its own modeling language, which developers use to describe the UI, or should it try and derive the UI automatically? Do modeling languages introduce error-prone duplication? Is automatic derivation too inflexible? Is there enough metadata to drive automatic derivation, or do we have to 'guess and fill in the gaps'?
Yes: n/a
No: Metawidget, Naked Objects, Woko
Production or Prototype
Should we expect UI generation to be able to be used in production applications, or only during a prototyping phase?
Prototype: n/a
Production: Metawidget, Naked Objects, Woko
Customisation
What sort of customisations of the generated UI are important? Graphics? Layouts? How should we facilitate them?
Pluggable: Metawidget, Woko
Search-based: Naked Objects
Bounds of Generation
Should we try to automatically generate the whole UI, or just pieces of it? Is generating the whole UI flexible enough? Is just generating pieces useful enough?
Whole UI: Naked Objects, Woko
Just pieces: Metawidget
Multiple Platforms
Is supporting multiple platforms (eg. desktop, web, mobile) important?
Yes: Naked Objects, Metawidget
No: Woko
Consistency
Given the same domain model, should we try and produce a consistent UI across all platforms? Does this risk a 'lowest common denominator'? Does tailoring uniquely to each platform introduce too much work for the developer?
Yes: n/a
No: Metawidget, Naked Objects
Diverse Architectures
Should the generator care about diverse architectures? Is mandating the technology stack of the application too restrictive? Or should we try to enforce 'good coding' that way? Does supporting multiple versions of everything introduce too much complexity? Is the ability to retrofit existing applications an important goal?
Yes: Metawidget
No: Naked Objects, Woko
Third Party Components
Should we support third-party UI components? What if they are not available on all platforms (eg. desktop, web)?
Support third-party: Metawidget
No explicit support: Naked Objects, Woko
Non-Domain Model Objects
Should we support modelling objects that are not strictly part of the domain? 'Solution space' objects, such as search screens that are user-centric (even role-centric) and not persisted to long-term storage?
Support non-domain model objects: Metawidget
No explicit support: Naked Objects
Convergence
Following conversations (some below, some in newer blog entries) with various parties, we note some convergence with future releases of products. Specifically:
Naked Objects: 4+ supports deriving metadata from different sources. Newer viewers may allow generating just pieces of the UI, and also modelling non-domain objects. Future versions want to support third-party components.
Woko: 2+ will allow more diverse architectures.
