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.
8 comments:
UI generation is not mainstream yet because there is no one-to-one mapping between what you show in the UI and the objects backing the UI. Secondly, at least in the enterprises I have worked for, the UI spec comes from UI designers, and not engineers, so it is natural to start from the UI prototype and make it production ready. Third, annotations and other metadata required for such systems pollute the code and finally, developers are nervous about losing control of the UI layout, if these frameworks fail at some point.
UI generation is useful in cases where the UI is closely related to the object model backing it. In many enterprise web apps, it is not the case.
Hi Richard,
here's where Naked Objects stands on these aspects:
* Static or Runtime: runtime
* Modeling Language: strongly baised to just building the metamodel from the code (eg annotations and naming conventions), though Naked Objects 4.0 abstracts this out so one could in theory define pick up this information from an external resource, eg an XML language
* Production or Prototype: production
* Customisation: customize per field, and also customize per domain object, by providing a search path for more specific through to more generic; standards such as CSS for styling;
* Bounds of Generation: as you know, has traditionally generated the whole UI, but newer viewers (eg scimpi.org) allows just pieces of it to be generated. It would make sense to reposition NO as the backend full stack that can be skinned in a variety of ways, MetaWidget being one obvious candidate
* Multiple Platforms: yes
* Consistency: I see a base level of semantics that a developer might reasonably expect any UI to support (in NO this is the application library, or "applib") and then a viewer-specific semantics (in a viewer-specific applib) also. Over time some semantics might migrate from viewer-specifics into the standard
* Diverse Architectures: our focus has predominantly been on enterprise apps (hence run as a webapp, or client/server with a socket/http remoting, also with a RESTful web service) but NO also runs as a standalone so deployments on a phone is also possible (and has been done experimentally); NO doesn't try to mandate the technology stack too much - instead we offer a variety of deployment options, eg just the metamodel+custom ui/persistence, or headless (custom UI), or full stack. I talk more about different deployment options in my book. In terms of retrofitting existing apps, we support a pojo domain model but realistically I think the target audience is for greenfield development.
* Third Party Components: not been a focus to date; it is the role of the viewer to define whether it supports UI components and how; this definition would be part of the viewer-specific applib, so wouldn't be supported in all environments
Cheers
Dan
Hi Rag,
Thank you for your valuable comments. I will address them in order:
Would you say your first point falls into the category of 'bounds of generation'? While I agree there is not generally a 1-to-1 mapping between the entire UI and the entire domain, in my enterprise apps the UI forms are generally backed by some Java Object - whether an actual domain object, or just a simple POJO for a search screen. I generally have to map the UI values into this object, so mapping it automatically is very useful.
I think your second point is also about 'bounds of generation'. I agree most of the screen is a designer's realm, but the names and types of fields are generally not open to debate (ie. they have to match the back-end). So you can auto-generate that bit, but leave the rest to the designer.
Your third point seems related to 'Modeling Language'. It sounds like you prefer something separate (non-polluting) to the domain model?
Your fourth point would seem to be addressed if we could get this whole thing standardized under a JSR, with multiple vendors and independant implementations (like JPA).
I hope I have summarised your points fairly?
Regards,
Richard.
Dan,
Thanks for your comments.
It sounds like there is a bit of convergence between NO and Metawidget, specifically:
1. NO abstracting out where it gets the metamodel from
2. Generating just pieces of the UI
Which is awesome. I'd be very keen to work through any issues you encounter making Metawidget the 'presentation layer' and repositioning NO as the backend full stack.
This would just leave a few areas still to debate:
1. Retrofitting or greenfield. For example, being able to use existing domain models is a big focus of JPA.
2. Third party component support
But let's take this one step at a time! I look forward to hearing how you go evaluating Metawidget for your presentation layer.
Regards,
Richard.
Hi Richard,
That's very interesting...
I've just commented on the TSS thread, as my post exceeded your blog's max allowed size.
Cheers
Remi
Dan: blog now updated with where NO sits. Please advise if I've got everything correct.
Remi: thanks for your post on...
http://www.theserverside.com/news/thread.tss?thread_id=58283
I've updated this post with where Woko sits. Please advise if I've got everything correct.
The good news is we seem to agree on far more than we disagree!
Hi Richard,
some clarifications and amplifications.
Dan
Modeling Language
- Naked Objects does allow for the metamodel to built up from non-code artefacts. I demonstrated this in my talk at TSSJS.
Customisation
- I think "search-based" rather than "parameter-based"
Bounds of Generation
- Naked Objects vanilla views are whole UI, but new viewers (including Scimpi.org) provide just pieces.
Consistency
- NO tries to support a base lowest common denominator (for the NO applib) but does not preclude viewers extending this.
Third Party Components
- on the roadmap, but nothing yet.
Thanks, Dan. Now updated. Hopefully Metawidget can help with your third-party component support :)
Post a Comment