It is not clear if it will be API or experimental in 3.2. Feature freeze is soon, and users of the framework are needed.
One interesting idea in jface.databinding is that UI elements and data models are treated the same. That means, the same mechanism (IUpdatable) is used to talk to the UI and to the data model. IUpdatableFactory creates an IUpdatable for an Object. Default IUpdatableFactory for SWT widgets and java classes (using bean properties) exist. This makes jface.databinding very flexible. But this flexibility makes it too complicated for my taste. I think it suffers a bit from trying to solve too many problems. If it would be limited to provide binding needed for typical dialogs (standard SWT elements), it would cover the 80% case. Getting 100% and being very simple is probably not possible.
I have created several similar databinding frameworks in my career. The first ones were based on ET++. Later I create a binding framework for swing and recently one for SWT. The major difference between my binding frameworks and the jface.databinding is that there are widgets on one side and a datamodel on the other (no attempt to unify data access and UI access). A "ValueAccessor" represents an attribute in a model. ValueAccessor provides information typically needed for dialogs:
value, valueAsString, isEnabled, isDefault, default, labelProvider (jface.databinding.IUpdatable in contrast, does not model enablement nor defaults nor label providers). My bindings is much less generic but it is much more targeted to bind a model to a UI. You then essentially bind a widget with a valueaccessor. My Binding class knows how to bind SWT widgets to ValueAccessors. There is already a kind of very simple databinding in eclipse: The preferences.FieldEditor classes. This is limited to binding to preferences and it also provides some automated layout. And it is not flexible enough to be a general binding fremawork. But I wish the jface.databinding would have some simplicity of the FieldEditors...
Maybe a simple layer on top of jface.databinding could help....
Anyway, I wonder what others think about the jface.databinding framework...
Resources:
I like that JFace Data Binding provides much more than just a GU-Model binding. But maybe it would be a good idea to settle this functionality within another package, and provide just a jface package with the appropriate IUpdatable factory.
ReplyDeleteWhen starting to use the framework, I was confused about using beans, widgets and viewers all the same way (I'm not a too experienced developer, though). Putting the Data Binding famework into another, more "generic" package (and maybe forcing the programmer to add the JFace Factory manually) could even help with that.
There can be (or rather should be) no doubt that the jface.databindings framework is an excellent idea.
ReplyDeleteLike you, it's something that I seem to have found myself re-inventing one way or another across the years in a number of number of different languages (Modula-2, C++, Magik, QuickBasic(!), Java etc.), so a standardised framework is most welcome.
That the framework does not differentiate between UI elements and data-models is a double edged sword.
On one hand it is cleaner and more elegant architectually, but on the other hand it means that the framework itself does not enforce any architectual rigour wrt. the clean separation of Model/View/Controller layers.
Personally, I think that the elegance outweighs the enforced rigour (good developers should design according to the paradigm rather than the implementation) but I know others that would disagree.
Beyond the elegance, my hope is that the framework will be lightweight (both at deign/dev-time and run-time). The previews that I have seen indicate that this is the direction and I commend those involves for that.
Whilst I'd love to answer the call for beta-users, I'm afraid that the effort to upgrade my environment to 3.2 can't be justified right now ... or rather the upgrade to the 3.2M# release, with the knowledge that I'll soon have to go to 3.2 (and the knowledge that many of my existing plugins will be broken in the meantime) is not one which I can justify.
When the situation changes, I'll certainly be getting my feet dirty though .
We just started big project based on RCP and it is very good, that now we have JFase Data Binding framework (DBF). I already use it in several dialogs. One weak thing in DBF is verbosity. You need to write too much code that is more or less same for many standard cases. Yes, this gives flexibility, but I think that we need some more compact and easy wrappers for standard cases, such as binding many controls to same bean, or binding selection in viewer to the group of control, with enable/disable on selection, etc. Good developer will create such utilities in any case to avoid iterative code, but it would be good to have them also standard.
ReplyDeleteBTW, we use RCP 3.1, but DBF works with it, so you are not forced to migrate to 3.2 to use DBF!