Re: [platform-ui-dev] JFace Databinding implementation
We have 5 model side binding concepts in core (attribute, list (1-d list), reference, container (2-d lists), and action). I was able to port attribute over to a model side observable in about 5 minutes. We had the ability for our version of the target observable to tell the binding framework which model side binding concept to use (the observables were a bit more tightly coupled). So in your framework I created a set of 5 properties and the user simply chooses one to pass into the modelDescription argument of the bind() method. I need to write some unit tests to prove the round trip behavior is working, but everything looks like your framework is generic enough for a framework like mine to plug into.
I am having some issues with the BindSpec concept because it seems like it promotes putting business logic on the client tier, but I can probably just hide the fact that it exists with a custom DataBindingContext.
We have a concept of binding an action to execute a method on the bound object. For instance you can have an action hooked up to a button named calculate which will call the calculate method on your object. I don't see that concept yet in the M1 release, but maybe it is coming.
As for the multi-threaded issue. We had a number of sets of model side observables (a set was an implementation of all 5 binding concepts) and one of them was multi-threaded. The set() method would get called on the ui thread (since it was in response to a ui event such as a lost focus) and the set() method would toss a runnable on our model queue which would get pulled off the queue at an arbitrary time in the future to get processed on the model thread. When our event manager saw an event that was destined for the target it would pop the event onto the ui thread. The get() method would do an executeAndWait(). Maybe I can do a proof of concept with an attribute observable.
I read the bugs reports and would like to see what proposal 1 looks like in code. I am a little leary about building generic stuff on top of static, wouldn't it be easier to just add some static stuff on top of the generic stuff? I'll have to look at the stuff in CVS to get a more up to date view of what is going on.
I have some free time if you need another set of eyes on any specific portion of the code.