Here are some Eclipse RCP Patterns and Anti-Patterns that Kevin Taylor and I distilled from our Eclipse RCP experience and the experiences of other developers who worked with us.
RCP Pattern Summaries:
Is The Job Done Yet?
To avoid application freezing when performing long-running tasks, use The Jobs API to improve usability
Summaries Are For Viewing; Details Are For Editing
Manage complexity and simplify application usage by utilizing Views to display data summaries and Editors to allow editing of data.
Serve Me A UI Screen Please
Enable Plugins to share UI screens (e.g. dialogs, wizards, panes) via a UI Screen broker Plugin.
One Plugin Per Library
Put each 3rd party library in its own Plugin. this prevents having to download the library during application updates every time its client Plugins are downloaded.
Compose Widget
When two or more screens have a similar cohesive subset of child widgets (e.g. address fields), extract those child widgets into an aggregate reusable widget to avoid repetition.
Instant Bean Brew
Instead of requiring users to hit save to persist data changes, improve UI efficiency by implementing the instant-persistence-paradigm using the JFace DataBinding framework.
RCP Anti-Pattern Summaries:
Everything But The Kitchen Sink
Placing all classes in a single Plugin can significantly increase download size during application updates. This also makes it harder to offer an application with configurable features.
Edit The Universe
Using a single editor to edit all data models (or a big number of them) causes information overload and makes it hard to discern structure or workflow.
The Obese Wizard
Placing too many controls on one page in a Wizard can impact usability negatively. Instead, break controls into multiple pages according to a logical flow.
Are Those Really Family?
Wizards, Editors, or Views that are in the same category, but do not follow consistent UI standards (e.g. margins, widget sizes, or colors), can hurt the professional look of the application and slow down the user from learning it.
But How Do I Fix It?
Your application is validating user input on "save" or on some other life-cycle event. When the validation finally occurs, the user has no idea how to fix it. Provide validation errors as soon as possible, preferably on loss of focus or character press. If that is not possible, have a way to help users navigate to the problem. If that is not possible, give users enough information so they can solve the problem.
3 comments:
Few thoughts:
1. Instead of putting each 3rd jars in its own plugin, I guess it is much more easier to have one plugin like a library-plugin, just for the libraries, and that library be made dependent on the main plugin, which should re-export on the packages. The advantage is, the application plugins can then, depend only on this one main plugin, but still can use any class from any of the 3rd party jars, and also that you donot have as many plugins as 3rd party jars.
2. JFace DataBinding framework is clumsy; I believe a much better job could have been done in much simplified way. Moreoever they didnot have any call-backs, so that any custom controls could also have potentially be used for the same frame-work. I didnot check their lastest implementation, so not sure if that had changed.
I'm very interested into implementing you're 'Instances Bean Brew' pattern using JFace data binding. More precisely, I'm interested to know how to use data binding with a persistence layer. Do you have any article to recommend me ?
This seems like a decent enough guide:
http://www.ibm.com/developerworks/opensource/tutorials/os-ecl-jfacedb3/os-ecl-jfacedb3-pdf.pdf
The key is to bind the View to the Model (or Presentation Model) bi-directionally, thus having user interactions trigger business logic in the Model directly (without the need for an explicit Controller), having business logic update other Model properties or data without touching the View, and then seeing property/data changes reflect in the View automatically due to data binding.
Good luck!
Andy
Post a Comment