Home » Archived » Visual Editor (VE) » Some initial thoughts on the databinding framework
|
| Re: Some initial thoughts on the databinding framework [message #114164 is a reply to message #113901] |
Fri, 23 December 2005 16:27   |
 Dave Orme
Messages: 424
Registered: July 2009 |
Senior Member |
|
|
Thanks for your detailed feedback!
Bill Snyder wrote:
> Hi there,
>
> I’ve been looking at the innards of the databinding framework today
> and had a few questions pertaining to the organization of the APIs.
> Not sure if this is the correct forum for these sorts of things -
> apologize beforehand if not...
No it's not. In the future, please put data binding threads on the
Eclipse.Platform or Eclipse.Platform.RCP newsgroups, and it really helps
if you put [DataBinding] at the beginning of the subject.
> Before I begin - Wow! It looks like a lot of work and thought went
> into the binding framework.
Thanks! In some senses, it's a third generation framework since the
people who designed and implemented it had done two complete data
binding frameworks before.
> 1- Was the Property object ever considered to own converters and
> validators? The Property object seems like _metadata_ for the actual
> domain-object values and a natural place for converters/validators.
Hmmmm.... Validators-- a qualified yes. Converters, no.
Suppose you have two "things", A and B and you want to bind them
together so that changes to A are "updated" in B and vice versa.
In this situation, A and B form a graph. A and B are the nodes, and
data binding makes up the edge (or arc or line) between A and B.
But A and B may be of different data types, so they can't be bound
unless there is a pair of data type conversion functions between them to
convert A's type to B's type and vice versa.
We believe that the data type conversion functions live on the edge
between A and B, and not on either A or B themselves.
Similarly, either A or B might be a more relaxed data type than the
other. For example, supposing A is a String and B is an int, A is a
more relaxed data type than B. In this situation, before we attempt to
convert A's String value to an int for B, we have to validate that A's
value *can* be converted to an integer to begin with.
Since this validation is associated with the data type conversion
function, we believe that this validation function also lives on the
edge between A and B.
That is why the call to bind() accepts 3 parameters:
bind(A, B, bindSpec)
bindSpec is the stuff associated with the edge in the data binding graph.
But you raise a valid point about business rule validation being mixed
with the validation associated with data type conversion. We have a bug
for that: See bug #120582 where I argue that business rule validation
needs to be associated with the business object.
In this context, your suggestion of putting this optional validator in
the Property object is very interesting. Thanks!
> That way each bound control can use the converter/validators from the
> bound property; you can then avoid making the binding API more
> verbose than it needs to be. (Specifically, the creation of
> Table/TreeDescriptions here taking converters and validators as
> arguments when a bound Property could suffice.)
I'm not sure I understand this suggestion...
Are you suggesting that TableDescription (for example), be changed to
something like:
td.addColumn(new Property(...))?
> 2- The converter object can be used to transform a data value to a UI
> component. This doesn’t seem quite right – shouldn’t converters be
> manipulating domain data and not be used to create UI controls? The
> only place I see it used is in Table/Tree bindings to create the
> custom label for the cells. Why not just let the developers set a
> LabelProvider directly on the viewers?
The person who wrote this part of the API is on vacation, and I can't
address it personally. I'll ask him to reply when he gets back.
> 3- Why is the term 'Updatable' used to represent bound data models? I
> think this can be confusing. Not all bound data will be changed
> (updated). Why not name it IBoundData or IBoundValue or DataModel,
> etc? I’ve read the wiki documents, but I still don’t quite understand
> completely…can someone shed some light on the subject?
Hmmmm... I guess we settled on this name because bound values are simply
values that are kept updated when an object that they depend on changes.
I guess if you really hate this name, you can file a bug and try to
rally support for some other name. We have until February to fight over
it on Bugzilla. ;-)
> These are just questions, and in no way criticisms, of what’s been
> done:)
>
> Looking forward to some discussion,
Thank you for your thoughtful comments!
Regards,
Dave Orme
--
Visual Editor Project lead
http://www.db4o.com -- The Open-source Java Object Database
http://xswt.sf.net -- XML-based SWT page description language
|
|
| |
| Re: Some initial thoughts on the databinding framework [message #611696 is a reply to message #113901] |
Fri, 23 December 2005 16:27 |
Dave Orme
Messages: 424
Registered: July 2009 |
Senior Member |
|
|
Thanks for your detailed feedback!
Bill Snyder wrote:
> Hi there,
>
> I’ve been looking at the innards of the databinding framework today
> and had a few questions pertaining to the organization of the APIs.
> Not sure if this is the correct forum for these sorts of things -
> apologize beforehand if not...
No it's not. In the future, please put data binding threads on the
Eclipse.Platform or Eclipse.Platform.RCP newsgroups, and it really helps
if you put [DataBinding] at the beginning of the subject.
> Before I begin - Wow! It looks like a lot of work and thought went
> into the binding framework.
Thanks! In some senses, it's a third generation framework since the
people who designed and implemented it had done two complete data
binding frameworks before.
> 1- Was the Property object ever considered to own converters and
> validators? The Property object seems like _metadata_ for the actual
> domain-object values and a natural place for converters/validators.
Hmmmm.... Validators-- a qualified yes. Converters, no.
Suppose you have two "things", A and B and you want to bind them
together so that changes to A are "updated" in B and vice versa.
In this situation, A and B form a graph. A and B are the nodes, and
data binding makes up the edge (or arc or line) between A and B.
But A and B may be of different data types, so they can't be bound
unless there is a pair of data type conversion functions between them to
convert A's type to B's type and vice versa.
We believe that the data type conversion functions live on the edge
between A and B, and not on either A or B themselves.
Similarly, either A or B might be a more relaxed data type than the
other. For example, supposing A is a String and B is an int, A is a
more relaxed data type than B. In this situation, before we attempt to
convert A's String value to an int for B, we have to validate that A's
value *can* be converted to an integer to begin with.
Since this validation is associated with the data type conversion
function, we believe that this validation function also lives on the
edge between A and B.
That is why the call to bind() accepts 3 parameters:
bind(A, B, bindSpec)
bindSpec is the stuff associated with the edge in the data binding graph.
But you raise a valid point about business rule validation being mixed
with the validation associated with data type conversion. We have a bug
for that: See bug #120582 where I argue that business rule validation
needs to be associated with the business object.
In this context, your suggestion of putting this optional validator in
the Property object is very interesting. Thanks!
> That way each bound control can use the converter/validators from the
> bound property; you can then avoid making the binding API more
> verbose than it needs to be. (Specifically, the creation of
> Table/TreeDescriptions here taking converters and validators as
> arguments when a bound Property could suffice.)
I'm not sure I understand this suggestion...
Are you suggesting that TableDescription (for example), be changed to
something like:
td.addColumn(new Property(...))?
> 2- The converter object can be used to transform a data value to a UI
> component. This doesn’t seem quite right – shouldn’t converters be
> manipulating domain data and not be used to create UI controls? The
> only place I see it used is in Table/Tree bindings to create the
> custom label for the cells. Why not just let the developers set a
> LabelProvider directly on the viewers?
The person who wrote this part of the API is on vacation, and I can't
address it personally. I'll ask him to reply when he gets back.
> 3- Why is the term 'Updatable' used to represent bound data models? I
> think this can be confusing. Not all bound data will be changed
> (updated). Why not name it IBoundData or IBoundValue or DataModel,
> etc? I’ve read the wiki documents, but I still don’t quite understand
> completely…can someone shed some light on the subject?
Hmmmm... I guess we settled on this name because bound values are simply
values that are kept updated when an object that they depend on changes.
I guess if you really hate this name, you can file a bug and try to
rally support for some other name. We have until February to fight over
it on Bugzilla. ;-)
> These are just questions, and in no way criticisms, of what’s been
> done:)
>
> Looking forward to some discussion,
Thank you for your thoughtful comments!
Regards,
Dave Orme
--
Visual Editor Project lead
http://www.db4o.com -- The Open-source Java Object Database
http://xswt.sf.net -- XML-based SWT page description language
|
|
| |
Goto Forum:
Current Time: Sat Oct 19 12:44:25 GMT 2024
Powered by FUDForum. Page generated in 0.03231 seconds |
] 
Search
Help
Register
Login
Home
