Home » Eclipse Projects » Eclipse Platform » [Databinding] Follow discussion
| [Databinding] Follow discussion [message #296534] |
Fri, 23 December 2005 12:16  |
Eclipse User |
|
|
|
> Thanks for your detailed feedback!
Thanks for taking time to respond :)
> > 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!
Makes sense. One thing I like about the binding framwork
is that it is easy to bind one POJO to another.
If it were concerned about binding *only* UI controls
to POJOs, then perhaps this would be a valid approach.
>
> > 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(...))?
>
Yes, something like that.
This is where I am coming from...
What I have now is a DataModel (something like the ModelObject in the
examples)
that is configured with PropertyData (which is meta data for the
properties in the DataModel).
The DataModel wraps any POJO and provides property change support. It is
also record-based, so it can wrap collections of POJOs. If I want to bind
to a TableViewer, I just pass the TableViewer, DataModel, and a list of
properties to use as the columns. The TableColumns/Editors are set up in
the binding using the PropertyData. The Converters and Validators are
there as well to translate from UI <-> DataMmodel.
bindingFactory.createTableViewerBinding(tableViewer,dataMode l,new String[]
{"firstName","lastName","married"});
I am just wondering if a similar setup with the table can happen in the
Eclipse databinding API.
> > 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? Ive read the wiki documents, but I still
> dont 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. ;-)
>
Nah :) Just wanted to know why. I'll buy that reasoning.
Kind Regards,
--Bill
|
|
|
| Re: [Databinding] Follow discussion [message #296620 is a reply to message #296534] |
Wed, 28 December 2005 04:59  |
| Eclipse User |
|
|
|
Where can I read more about the design and idea of this. We have also
written our own Databinding-Framework which we'd like to release in Q1
to the public.
Tom
Bill Snyder wrote:
>> Thanks for your detailed feedback!
>
> Thanks for taking time to respond :)
>
>> > 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!
>
>
> Makes sense. One thing I like about the binding framwork
> is that it is easy to bind one POJO to another. If it were concerned
> about binding *only* UI controls to POJOs, then perhaps this would be a
> valid approach.
>
>>
>> > 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(...))?
>>
>
> Yes, something like that.
> This is where I am coming from...
> What I have now is a DataModel (something like the ModelObject in the
> examples) that is configured with PropertyData (which is meta data for
> the properties in the DataModel).
> The DataModel wraps any POJO and provides property change support. It is
> also record-based, so it can wrap collections of POJOs. If I want to
> bind to a TableViewer, I just pass the TableViewer, DataModel, and a
> list of properties to use as the columns. The TableColumns/Editors are
> set up in the binding using the PropertyData. The Converters and
> Validators are there as well to translate from UI <-> DataMmodel.
> bindingFactory.createTableViewerBinding(tableViewer,dataMode l,new
> String[] {"firstName","lastName","married"});
>
> I am just wondering if a similar setup with the table can happen in the
> Eclipse databinding API.
>
>> > 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? Ive read the wiki documents, but I still
>> dont 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. ;-)
>>
>
> Nah :) Just wanted to know why. I'll buy that reasoning.
>
> Kind Regards,
>
> --Bill
>
|
|
| |
Goto Forum:
Current Time: Wed May 07 16:12:12 EDT 2025
Powered by FUDForum. Page generated in 0.03107 seconds |
Home