Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 127738

Summary:	[DataBinding] Support custom getters/setters
Product:	[Eclipse Project] Platform	Reporter:	Aaron Digulla <digulla>
Component:	UI	Assignee:	Boris Bokowski <bokowski>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P5	CC:	djo
Version:	3.2	Keywords:	helpwanted
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Aaron Digulla

2006-02-14 10:51:39 EST

I have a model which contains text nodes in different languages.

To get the summary of the text node for a language, you have to call "getSummary(Lang)".

The current implementation of the data bindings makes it impossible to overide the reading of properties. I've created a patch with refactors all the code which reads attributes to use PropertyHelper and then I've patched this class to allow custom property accessor factories.

Now, I can register a binding to the property "text.summary(en)".

This solves my problem but I'm not sure if it's the right approach. Any pointers?

Comment 1 Boris Bokowski

2006-02-14 12:46:14 EST

Is what you are doing backed by the Java Beans specification?

Maybe the easiest thing would be to write your own updatable factory for this special case. If collection properties are not language specific, you would only have to write your own version of JavaBeansUpdatableValue.

However, before you put a lot of effort into this, I should give you a heads up that we are currently refactoring the framework, so you might want to wait a couple of days until we are done with the refactoring.

Comment 2 Aaron Digulla

2006-02-14 14:30:06 EST

> Is what you are doing backed by the Java Beans specification?

Probably not. I think for Java Beans, your getters must be without arguments.

I guess I could solve the problem with an interface but I'd really like a solution where you can register special getters/setters which is not possible with the current framework.

OTOH, my current solution lacks flexibility because I can only register my accessor factories globally which means that you'll have them anywhere even if you need something else in one place.

> we are currently refactoring the framework

What are the chances of accepting my patch after M5?

Comment 3 Boris Bokowski

2006-02-14 14:39:27 EST

> I guess I could solve the problem with an interface but I'd really like a
> solution where you can register special getters/setters which is not possible
> with the current framework.

This is not possible with the provided BeansUpdatableFactory, but should be possible with a custom updatable factory.

> What are the chances of accepting my patch after M5?

I would have to look at the patch. In general, we like community involvement!

Comment 4 Boris Bokowski

2006-02-14 14:40:20 EST

Sorry for the noise, I accidentally clicked a radio button and then Commit instead of just Commit.

Comment 5 Aaron Digulla

2006-03-04 17:25:52 EST

I'm trying to adjust my patches to your changes.

Currently, I'm getting this exception:

BindingException: could not find updatable for Property(de.philmanndark.writertool.model.impl.AuthorImpl, content.lcontent().summary, ...)

Background: This happens in the details view because nothing in the master is selected. What I don't understand is why it works for "simple" properties (like "name")? Is there some magic when the UpdatableValue is the current selection?

Comment 6 Aaron Digulla

2006-03-04 18:03:55 EST

Maybe the best solution would be to supply an abstract interface which is used to get and set values out of objects. One way would be the Bean API but that would allow complex ways.

The first step in this direction would be to get rid of the property names which show up in a whole lot of places. These make it very hard to exchange the current getter/setter system with something more flexible.

Comment 7 Boris Bokowski

2007-06-26 15:45:12 EDT

I would suggest writing your own factory for observable objects, and use BeansObservables or SWTObservables as an example. I don't believe we should try to solve this within the framework.