Eclipse Community Forums: Eclipse Platform » [DataBinding] Best practices on creating the DataBindingContext

Home » Eclipse Projects » Eclipse Platform » [DataBinding] Best practices on creating the DataBindingContext

[DataBinding] Best practices on creating the DataBindingContext [message #311665]

Thu, 18 January 2007 20:43

Eclipse User

Originally posted by: mbayly.nospam.telus.net

Sorry, today seems to be the day for databinding questions!

I noticed that creating a DataBindingContext, particularly the DefaultBindSupportFactory,
is quite a slow operation.
I have a view with a number of panels/components in it and initially I had
each component setting up their own DataBindingContext.
But this seems to add quite a lot to the time it takes to display the view.

So now I've modified it to use a single context for the whole view. However,
its a view that gets opened and closed quite a lot so I decided to make the
DefaultBindSupportFactory static which may not be a good thing.

But in general - what are the guidelines for creating contexts in a Rich
Client app with many windows etc. Is it a good idea to try and tie the contexts
closely to the windows that are using them - otherwise could you end up storing
a lot of binding information for controls that are now destroyed. i.e. leak
memory over time. Are some of the factories relatively stateless e.g. the
DefaultBindSupportFactory and could potentially be shared?

Thanks for any insights
Martin

Re: [DataBinding] Best practices on creating the DataBindingContext [message #311675 is a reply to message #311665]

Fri, 19 January 2007 00:56

Eclipse User

You're referring mostly to the old APIs. I don't recall how expensive
they were to create and maintain. I'm sorry but I'm not sure I'm going to
be much help when referring to the old APIs.

In the latest APIs there are no factories and a DBC should be pretty
lightweight. So I wouldn't be too concerned with creating and disposing
of them. But in the lastest APIs the DBC is a way to maintain Bindings.
I'd align DBCs with the validation and update policies of my bindings. So
if you have some widgets that have expensive validation and you want to
defer that until the last moment possible you could do so by invoking
updateModel() on the DBC which would update the models of each binding.
And at the same time there could be others that you want to update the
model on change so it wouldn't make sense to force an update at the same
time as those with the expensive validation.

My point is I'd align the life cycle of the DBCs with the view and then to
organize them with the validation and update needs of the widgetry of the
view. And I'd also make sure to dispose of them when the widgets are
disposed.

-brad

Re: [DataBinding] Best practices on creating the DataBindingContext [message #311677 is a reply to message #311665]

Fri, 19 January 2007 01:07

Eclipse User

martin wrote:
> Sorry, today seems to be the day for databinding questions!
>
> I noticed that creating a DataBindingContext, particularly the
> DefaultBindSupportFactory, is quite a slow operation.
> I have a view with a number of panels/components in it and initially I
> had each component setting up their own DataBindingContext.
> But this seems to add quite a lot to the time it takes to display the view.
>
> So now I've modified it to use a single context for the whole view.

Yes!

> However, its a view that gets opened and closed quite a lot so I decided
> to make the DefaultBindSupportFactory static which may not be a good thing.

This is how we do it. (our app is 3 million lines long now)

> But in general - what are the guidelines for creating contexts in a Rich
> Client app with many windows etc. Is it a good idea to try and tie the
> contexts closely to the windows that are using them - otherwise could
> you end up storing a lot of binding information for controls that are
> now destroyed. i.e. leak memory over time. Are some of the factories
> relatively stateless e.g. the DefaultBindSupportFactory and could
> potentially be shared?

A few thoughts:

1) Have a single factory and make it static.

2) If you're concerned about performance, you can have your factory
create and hold a "patriarch" DBC. Then when someone asks for a new
one, the factory can:

DataBindingContext result = new DataBindingContext(rootContext);
return result;

This avoids the overhead of adding the factories to every DBC.

3) You definitely did the right thing creating one DBC for your entire
view. :-)

Best regards,

Dave Orme

Previous Topic:	[DataBinding] Virtual tables, composite tables
Next Topic:	enablement in org.eclipse.ui.actionSets

Goto Forum:

-=] Back to Top [=-

Current Time: Tue Jul 22 15:37:28 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter