Data Binding framework

[eliasb...@gmail.com]

Hello everyone,

I have an idea that could form the basis of a data-binding framework
for GWT.
Using the new repository features of TIBCO PageBus 1.2 framework
(http://www.tibco.com/devnet/pagebus , download package and read the
dev guide) publishers and subscribers could interact and exchange
modified values just like data binding functionality requires, where
publisher is the UI component and subscriber the model/logic or vice
versa.

I already have a project providing support for TIBCO PageBus 1.1
functionality (publish/subscribe for events and associated data) in
GWT (http://code.google.com/p/tibcopagebus4gwt/) and I intend to
extend it with the new repository features in TIBCO PageBus 1.2

Comments and ideas for integration are welcome.

[Miguel Ping]

Hi,

From the diagram it seems that pageBus is a general purpose 'mini-js-
Java-message-system' implementation. Are you thinking of doing
databinding using one topic per bean instance or something like that?
Kinda like pub-sub between beans and widgets? What are the advantages
of an approach like pageBus vs. 'traditional' data binding?

On Jan 26, 1:20 pm, "eliasbala...@gmail.com" <eliasbala...@gmail.com>
wrote:

> Hello everyone,
>
> I have an idea that could form the basis of a data-binding framework
> for GWT.
> Using the new repository features of TIBCO PageBus 1.2 framework

> (http://www.tibco.com/devnet/pagebus, download package and read the

[Henri Karapuu]

> I already have a project providing support for TIBCO PageBus 1.1
> functionality (publish/subscribe for events and associated data) in
> GWT (http://code.google.com/p/tibcopagebus4gwt/) and I intend to
> extend it with the new repository features in TIBCO PageBus 1.2

I started just last week a thread about getting reflection and data
binding support, and i think data binding is important and should be
added to core GWT.

However, the exact proposed approach -- abducting native JS library
from third party and retrofitting it to GWT -- does not sound optimal.

/Henri Karapuu

[eliasb...@gmail.com]

> data binding is important and should be added to core GWT.

I can't agree more

> However, the exact proposed approach -- abducting native JS library
> from third party and retrofitting it to GWT -- does not sound optimal.

The difference with other binding attempts I have so far observed
(Eclipse JFace binding translations to GWT) is that this approach does
not require threads which are difficult to have in a browser
environment (google gears has a solution for this but it is not a
native thing).
Another thing to consider is that PageBus is very stable and very fast
so this makes it a good candidate.
I must admit it does not sound optimal enough but at least it covers
some areas of the problem.
Also, reusing things and building artifacts on top of other artifacts
is fundamental practice in structured and OO programming.
What do you think?

[Henri Karapuu]

> The difference with other binding attempts I have so far observed
> (Eclipse JFace binding translations to GWT) is that this approach does
> not require threads

I checked that project briefly some time ago, and my feeling was that
it ain't gonna fly.

However, there actually is something like half a dozen implementations
(ours one of them), that solve the problem by first adding 'faked'
reflection support, and then use the reflective/dynamic invocation
support to fiddle with the properties of widgets. The data binding
itself is then relatively trivial, and can be implemented in way that
supports listening of specific properties (main point of publisher/
subscriber), but still follows closely GWT's event idioms
(SourcesPropertyEvents etc. etc.).

There is also other school of data binders, they modify the widget so
that the widget has direct reference to the model (a.k.a data aware
widgets).

The reflective style has the advantage of working with the vanilla GWT
widgets, as well as all third party widgets, while the data aware
style has benefit of being 'closer' to data, which means that things
like paginated tables come easier to implement.

> Also, reusing things and building artifacts on top of other artifacts
> is fundamental practice in structured and OO programming.
> What do you think?

Implementing publisher / subscriber pattern is pretty trivial. The
difficult thing is wiring data binding nicely with widgets, specially
in a way (as John pointed out to my ignorant ears in the other thread)
that does not kill performance and bloat the code. I think by doing
clean implementation instead of using 3rd party java script code the
difficult issues are easier to address, and we'll get also interface
that is typical for GWT programming style, instead of TIBCO's.

/Henri Karapuu