Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [Databinding] Creating a ComboViewer for an EReference
[Databinding] Creating a ComboViewer for an EReference [message #423309] Fri, 26 September 2008 19:48 Go to next message
Eclipse UserFriend
Originally posted by: jconlon.apache.org

I'm trying to create a ComboViewer for an arbitrary EReference but I'm
stumped on how to set up the ComboViewer with the EMF databinding.

//The main problem is I don't know how to create the initial
//IObservableList for the comboViewer

IObservableList comboViewerChoices = ??;

//After that I think it flows like this...
ObservableListContentProvider contentProvider = new
ObservableListContentProvider();

IObservableMap[] attributeMaps =
EMFObservables.observeMaps(
contentProvider.getKnownElements(),
new EStructuralFeature[]
{ eReference.getEOpposite() });

comboViewer.setContentProvider(contentProvider);
comboViewer.setLabelProvider(
new ObservableMapLabelProvider(
attributeMaps));
comboViewer.setInput(comboViewerChoices);


//Then to set up the selection...
dataBindingContext.bindValue(
ViewersObservables.observeSingleSelection(comboViewer),
EMFEditObservables.observeValue(
AdapterFactoryEditingDomain
.getEditingDomainFor(eObject),
eObject, eReference),
tToMStrategy, // TargetToModel
mToTStrategy);// ModelToTarget

any ideas, would be appreciated,
John
Re: [Databinding] Creating a ComboViewer for an EReference [message #423324 is a reply to message #423309] Sat, 27 September 2008 15:08 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30813
Registered: July 2009
Senior Member
John,

Hopefully Tom or someone else will see your question because I just
don't have enough experience...


John E. Conlon wrote:
> I'm trying to create a ComboViewer for an arbitrary EReference but I'm
> stumped on how to set up the ComboViewer with the EMF databinding.
>
> //The main problem is I don't know how to create the initial
> //IObservableList for the comboViewer
>
> IObservableList comboViewerChoices = ??;
>
> //After that I think it flows like this...
> ObservableListContentProvider contentProvider = new
> ObservableListContentProvider();
>
> IObservableMap[] attributeMaps =
> EMFObservables.observeMaps(
> contentProvider.getKnownElements(),
> new EStructuralFeature[]
> { eReference.getEOpposite() });
>
> comboViewer.setContentProvider(contentProvider);
> comboViewer.setLabelProvider(
> new ObservableMapLabelProvider(
> attributeMaps));
> comboViewer.setInput(comboViewerChoices);
>
>
> //Then to set up the selection...
> dataBindingContext.bindValue(
> ViewersObservables.observeSingleSelection(comboViewer),
> EMFEditObservables.observeValue(
> AdapterFactoryEditingDomain
> .getEditingDomainFor(eObject),
> eObject, eReference),
> tToMStrategy, // TargetToModel
> mToTStrategy);// ModelToTarget
>
> any ideas, would be appreciated,
> John
Re: [Databinding] Creating a ComboViewer for an EReference [message #423330 is a reply to message #423309] Sun, 28 September 2008 15:27 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6518
Registered: July 2009
Senior Member
Hi John,

This has to be an ObservableList (EMFObservable#observeList(),
EMFObservable#observeDetailList(), WritableList()).

The question is whether you need this?

Do you expect that:
- the content is modified (elements removed/added)
- the attribute of an element is modified

Please take into consideration that an
ObservableListContentProvider/EMFObservables.observeMaps is quite heavy
if you have a big number of elements because a Listener is added for
every map-element for every attribute.

Tom

John E. Conlon schrieb:
> I'm trying to create a ComboViewer for an arbitrary EReference but I'm
> stumped on how to set up the ComboViewer with the EMF databinding.
>
> //The main problem is I don't know how to create the initial
> //IObservableList for the comboViewer
>
> IObservableList comboViewerChoices = ??;
>
> //After that I think it flows like this...
> ObservableListContentProvider contentProvider = new
> ObservableListContentProvider();
>
> IObservableMap[] attributeMaps =
> EMFObservables.observeMaps(
> contentProvider.getKnownElements(),
> new EStructuralFeature[]
> { eReference.getEOpposite() });
>
> comboViewer.setContentProvider(contentProvider);
> comboViewer.setLabelProvider(
> new ObservableMapLabelProvider(
> attributeMaps));
> comboViewer.setInput(comboViewerChoices);
>
>
> //Then to set up the selection...
> dataBindingContext.bindValue(
> ViewersObservables.observeSingleSelection(comboViewer),
> EMFEditObservables.observeValue(
> AdapterFactoryEditingDomain
> .getEditingDomainFor(eObject),
> eObject, eReference),
> tToMStrategy, // TargetToModel
> mToTStrategy);// ModelToTarget
>
> any ideas, would be appreciated,
> John


--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
Re: [Databinding] Creating a ComboViewer for an EReference [message #423338 is a reply to message #423309] Mon, 29 September 2008 05:38 Go to previous messageGo to next message
Boris Bokowski is currently offline Boris BokowskiFriend
Messages: 272
Registered: July 2009
Senior Member
"John E. Conlon" <jconlon@apache.org> wrote in message
news:gbje9m$5b3$1@build.eclipse.org...
> I'm trying to create a ComboViewer for an arbitrary EReference but I'm
> stumped on how to set up the ComboViewer with the EMF databinding.
>
> //The main problem is I don't know how to create the initial
> //IObservableList for the comboViewer
>
> IObservableList comboViewerChoices = ??;

If all you have is an object eReference of type EReference, then the list of
choices would consist of all instances of the EClass returned from
eReference.getEReferenceType(). I couldn't find a method like
EClass.getAllInstances() and doubt that such a thing exists, so I guess you
will have to parameterize your solution so that a list of choices can be
provided depending on the concrete case. Sometimes, any instance will do
(e.g., pick any country); but you could also have constraints that narrow
down the choices (e.g., pick one of the official languages of the previously
chosen country).

Boris
Re: [Databinding] Creating a ComboViewer for an EReference [message #423348 is a reply to message #423338] Mon, 29 September 2008 11:36 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30813
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------020108040700050208030308
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Boris,

ItemPropertyDescriptor.getReachableObjectsOfType is a static utility
that does this type of thing. Basically walking the entire reachable
collection of EObjects for things of a suitable type. As you say, often
it's filtered to satisfy some constraints...


Boris Bokowski wrote:
> "John E. Conlon" <jconlon@apache.org> wrote in message
> news:gbje9m$5b3$1@build.eclipse.org...
>
>> I'm trying to create a ComboViewer for an arbitrary EReference but I'm
>> stumped on how to set up the ComboViewer with the EMF databinding.
>>
>> //The main problem is I don't know how to create the initial
>> //IObservableList for the comboViewer
>>
>> IObservableList comboViewerChoices = ??;
>>
>
> If all you have is an object eReference of type EReference, then the list of
> choices would consist of all instances of the EClass returned from
> eReference.getEReferenceType(). I couldn't find a method like
> EClass.getAllInstances() and doubt that such a thing exists, so I guess you
> will have to parameterize your solution so that a list of choices can be
> provided depending on the concrete case. Sometimes, any instance will do
> (e.g., pick any country); but you could also have constraints that narrow
> down the choices (e.g., pick one of the official languages of the previously
> chosen country).
>
> Boris
>
>
>

--------------020108040700050208030308
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Boris,<br>
<br>
ItemPropertyDescriptor.getReachableObjectsOfType is a static utility
that does this type of thing.&nbsp; Basically walking the entire reachable
collection of EObjects for things of a suitable type.&nbsp; As you say,
often it's filtered to satisfy some constraints...<br>
<br>
<br>
Boris Bokowski wrote:
<blockquote cite="mid:gbppku$qov$1@build.eclipse.org" type="cite">
<pre wrap="">"John E. Conlon" <a class="moz-txt-link-rfc2396E" href="mailto:jconlon@apache.org">&lt;jconlon@apache.org&gt;</a> wrote in message
<a class="moz-txt-link-freetext" href="news:gbje9m$5b3$1@build.eclipse.org">news:gbje9m$5b3$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">I'm trying to create a ComboViewer for an arbitrary EReference but I'm
stumped on how to set up the ComboViewer with the EMF databinding.

//The main problem is I don't know how to create the initial
//IObservableList for the comboViewer

IObservableList comboViewerChoices = ??;
</pre>
</blockquote>
<pre wrap=""><!---->
If all you have is an object eReference of type EReference, then the list of
choices would consist of all instances of the EClass returned from
eReference.getEReferenceType(). I couldn't find a method like
EClass.getAllInstances() and doubt that such a thing exists, so I guess you
will have to parameterize your solution so that a list of choices can be
provided depending on the concrete case. Sometimes, any instance will do
(e.g., pick any country); but you could also have constraints that narrow
down the choices (e.g., pick one of the official languages of the previously
chosen country).

Boris


</pre>
</blockquote>
</body>
</html>

--------------020108040700050208030308--
Re: [Databinding] Creating a ComboViewer for an EReference [message #423373 is a reply to message #423330] Mon, 29 September 2008 15:31 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: jconlon.apache.org

Hi Tom,

> ObservableListContentProvider/EMFObservables.observeMaps is quite heavy
Thanks for pointing this out.
I expect that ...
ObservableMap map = EMFObservables.observeMap(cp.getKnownElements(),
eReference.getEOpposite());
ObservableMapLabelProvider lp = new ObservableMapLabelProvider(map);

is pretty much equivalent to EMFObservables.observeMaps and also
heavywieght.


thanks,
John


Tom Schindl wrote:
> Hi John,
>
> This has to be an ObservableList (EMFObservable#observeList(),
> EMFObservable#observeDetailList(), WritableList()).
>
> The question is whether you need this?
>
> Do you expect that:
> - the content is modified (elements removed/added)
> - the attribute of an element is modified
>
> Please take into consideration that an
> ObservableListContentProvider/EMFObservables.observeMaps is quite heavy
> if you have a big number of elements because a Listener is added for
> every map-element for every attribute.
>
> Tom
>
> John E. Conlon schrieb:
>> I'm trying to create a ComboViewer for an arbitrary EReference but I'm
>> stumped on how to set up the ComboViewer with the EMF databinding.
>>
>> //The main problem is I don't know how to create the initial
>> //IObservableList for the comboViewer
>>
>> IObservableList comboViewerChoices = ??;
>>
>> //After that I think it flows like this...
>> ObservableListContentProvider contentProvider = new
>> ObservableListContentProvider();
>>
>> IObservableMap[] attributeMaps =
>> EMFObservables.observeMaps(
>> contentProvider.getKnownElements(),
>> new EStructuralFeature[]
>> { eReference.getEOpposite() });
>>
>> comboViewer.setContentProvider(contentProvider);
>> comboViewer.setLabelProvider(
>> new ObservableMapLabelProvider(
>> attributeMaps));
>> comboViewer.setInput(comboViewerChoices);
>>
>>
>> //Then to set up the selection...
>> dataBindingContext.bindValue(
>> ViewersObservables.observeSingleSelection(comboViewer),
>> EMFEditObservables.observeValue(
>> AdapterFactoryEditingDomain
>> .getEditingDomainFor(eObject),
>> eObject, eReference),
>> tToMStrategy, // TargetToModel
>> mToTStrategy);// ModelToTarget
>>
>> any ideas, would be appreciated,
>> John
>
>
Re: [Databinding] Creating a ComboViewer for an EReference [message #423375 is a reply to message #423348] Mon, 29 September 2008 15:59 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: jconlon.apache.org

Ed, Boris

Currently I am using propertyDescriptor.getChoiceOfValues(object) to
build the list.

<snip>
List<Object> choices = new ArrayList<Object>();
for (Object object2 : propertyDescriptor.getChoiceOfValues(object)) {
//Viewers dont like nulls
if (object2 != null) {
choices.add(object2);
}
}

if (choices.isEmpty()) {
return;
}
comboViewer.setContentProvider(new ArrayContentProvider());
comboViewer.setLabelProvider(new
AdapterFactoryLabelProvider(adapterFactory));
comboViewer.setInput(choices.toArray());

</snip>

Would ItemPropertyDescriptor.getReachableObjectsOfType have been better?

Although I can create a list, and could turn it into an ObservableList,
I couldn't get it to work with the databinding contentProvider and
labelProvider so...

I took the more traditional path and refactored so as not to require an
ObservableList after all for the input to the comboViewer's list of
choices. (Still curious how this could be done with databinding though.)

But I do still use databinding to bind the combo selection to the model
element like:

dataBindingContext.bindValue(
ViewersObservables.observeSingleSelection(comboViewer),
EMFEditObservables.observeValue(
AdapterFactoryEditingDomain
.getEditingDomainFor(eObject),
eObject,
eStructuralFeature),
tToMStrategy,
mToTStrategy
);


Now my remaining question has to do with how I can create the selection
list and bindings to enable unsetting of the eObject's reference?

Is there a consensus how to do this?

thanks,
John




Ed Merks wrote:
> Boris,
>
> ItemPropertyDescriptor.getReachableObjectsOfType is a static utility
> that does this type of thing. Basically walking the entire reachable
> collection of EObjects for things of a suitable type. As you say, often
> it's filtered to satisfy some constraints...
>
>
> Boris Bokowski wrote:
>> "John E. Conlon" <jconlon@apache.org> wrote in message
>> news:gbje9m$5b3$1@build.eclipse.org...
>>
>>> I'm trying to create a ComboViewer for an arbitrary EReference but
>>> I'm stumped on how to set up the ComboViewer with the EMF databinding.
>>>
>>> //The main problem is I don't know how to create the initial
>>> //IObservableList for the comboViewer
>>>
>>> IObservableList comboViewerChoices = ??;
>>>
>>
>> If all you have is an object eReference of type EReference, then the
>> list of choices would consist of all instances of the EClass returned
>> from eReference.getEReferenceType(). I couldn't find a method like
>> EClass.getAllInstances() and doubt that such a thing exists, so I
>> guess you will have to parameterize your solution so that a list of
>> choices can be provided depending on the concrete case. Sometimes, any
>> instance will do (e.g., pick any country); but you could also have
>> constraints that narrow down the choices (e.g., pick one of the
>> official languages of the previously chosen country).
>>
>> Boris
>>
>>
>
Re: [Databinding] Creating a ComboViewer for an EReference [message #423376 is a reply to message #423375] Mon, 29 September 2008 16:08 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30813
Registered: July 2009
Senior Member
John,

Comments below.

John E. Conlon wrote:
> Ed, Boris
>
> Currently I am using propertyDescriptor.getChoiceOfValues(object) to
> build the list.
>
> <snip>
> List<Object> choices = new ArrayList<Object>();
> for (Object object2 : propertyDescriptor.getChoiceOfValues(object)) {
> //Viewers dont like nulls
> if (object2 != null) {
> choices.add(object2);
> }
> }
>
> if (choices.isEmpty()) {
> return;
> }
> comboViewer.setContentProvider(new ArrayContentProvider());
> comboViewer.setLabelProvider(new
> AdapterFactoryLabelProvider(adapterFactory));
> comboViewer.setInput(choices.toArray());
>
> </snip>
>
> Would ItemPropertyDescriptor.getReachableObjectsOfType have been better?
No, because that's exactly how it's implemented already. :-P
>
> Although I can create a list, and could turn it into an
> ObservableList, I couldn't get it to work with the databinding
> contentProvider and labelProvider so...
Don't you just build the list each time instead of trying to maintain it
dynamically?
>
> I took the more traditional path and refactored so as not to require
> an ObservableList after all for the input to the comboViewer's list of
> choices. (Still curious how this could be done with databinding though.)
>
> But I do still use databinding to bind the combo selection to the
> model element like:
>
> dataBindingContext.bindValue(
> ViewersObservables.observeSingleSelection(comboViewer),
> EMFEditObservables.observeValue(
> AdapterFactoryEditingDomain
> .getEditingDomainFor(eObject),
> eObject,
> eStructuralFeature),
> tToMStrategy,
> mToTStrategy
> );
>
>
> Now my remaining question has to do with how I can create the
> selection list and bindings to enable unsetting of the eObject's
> reference?
We alway just add null to the list, but for unsettable features, that's
not really sufficient, so we rely on the Restore default value button to
actually do the eUnset.
>
> Is there a consensus how to do this?
I suppose another special value...
>
> thanks,
> John
>
>
>
>
> Ed Merks wrote:
>> Boris,
>>
>> ItemPropertyDescriptor.getReachableObjectsOfType is a static utility
>> that does this type of thing. Basically walking the entire reachable
>> collection of EObjects for things of a suitable type. As you say,
>> often it's filtered to satisfy some constraints...
>>
>>
>> Boris Bokowski wrote:
>>> "John E. Conlon" <jconlon@apache.org> wrote in message
>>> news:gbje9m$5b3$1@build.eclipse.org...
>>>
>>>> I'm trying to create a ComboViewer for an arbitrary EReference but
>>>> I'm stumped on how to set up the ComboViewer with the EMF databinding.
>>>>
>>>> //The main problem is I don't know how to create the initial
>>>> //IObservableList for the comboViewer
>>>>
>>>> IObservableList comboViewerChoices = ??;
>>>>
>>>
>>> If all you have is an object eReference of type EReference, then the
>>> list of choices would consist of all instances of the EClass
>>> returned from eReference.getEReferenceType(). I couldn't find a
>>> method like EClass.getAllInstances() and doubt that such a thing
>>> exists, so I guess you will have to parameterize your solution so
>>> that a list of choices can be provided depending on the concrete
>>> case. Sometimes, any instance will do (e.g., pick any country); but
>>> you could also have constraints that narrow down the choices (e.g.,
>>> pick one of the official languages of the previously chosen country).
>>>
>>> Boris
>>>
>>>
>>
Re: [Databinding] Creating a ComboViewer for an EReference [message #423378 is a reply to message #423373] Mon, 29 September 2008 16:15 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6518
Registered: July 2009
Senior Member
John E. Conlon schrieb:
> Hi Tom,
>
>> ObservableListContentProvider/EMFObservables.observeMaps is quite heavy
> Thanks for pointing this out.
> I expect that ...
> ObservableMap map = EMFObservables.observeMap(cp.getKnownElements(),
> eReference.getEOpposite());
> ObservableMapLabelProvider lp = new ObservableMapLabelProvider(map);
>
> is pretty much equivalent to EMFObservables.observeMaps and also
> heavywieght.

Yes, if you don't expect the label of the operation to change it is not
wise to create an IObservableMap because of the many many listeners
attached to the many many objects.

Tom

--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
Re: [Databinding] Creating a ComboViewer for an EReference [message #423389 is a reply to message #423376] Mon, 29 September 2008 18:35 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: jconlon.apache.org

Ed,

See inline...

Ed Merks wrote:
> John,
>
> Comments below.
>
> John E. Conlon wrote:
>> Ed, Boris
>>
>> Currently I am using propertyDescriptor.getChoiceOfValues(object) to
>> build the list.
>>
>> <snip>
>> List<Object> choices = new ArrayList<Object>();
>> for (Object object2 : propertyDescriptor.getChoiceOfValues(object)) {
>> //Viewers dont like nulls
>> if (object2 != null) {
>> choices.add(object2);
>> }
>> }
>>
>> if (choices.isEmpty()) {
>> return;
>> }
>> comboViewer.setContentProvider(new ArrayContentProvider());
>> comboViewer.setLabelProvider(new
>> AdapterFactoryLabelProvider(adapterFactory));
>> comboViewer.setInput(choices.toArray());
>>
>> </snip>
>>
>> Would ItemPropertyDescriptor.getReachableObjectsOfType have been better?
> No, because that's exactly how it's implemented already. :-P
>>
>> Although I can create a list, and could turn it into an
>> ObservableList, I couldn't get it to work with the databinding
>> contentProvider and labelProvider so...
> Don't you just build the list each time instead of trying to maintain it
> dynamically?

Right, the comboViewer and list is being created each time so there is
no need for an ongoing observation.
>>
>> I took the more traditional path and refactored so as not to require
>> an ObservableList after all for the input to the comboViewer's list of
>> choices. (Still curious how this could be done with databinding though.)
>>
>> But I do still use databinding to bind the combo selection to the
>> model element like:
>>
>> dataBindingContext.bindValue(
>> ViewersObservables.observeSingleSelection(comboViewer),
>> EMFEditObservables.observeValue(
>> AdapterFactoryEditingDomain
>> .getEditingDomainFor(eObject),
>> eObject,
>> eStructuralFeature),
>> tToMStrategy,
>> mToTStrategy
>> );
>>
>>
>> Now my remaining question has to do with how I can create the
>> selection list and bindings to enable unsetting of the eObject's
>> reference?
> We alway just add null to the list, but for unsettable features, that's
> not really sufficient, so we rely on the Restore default value button to
> actually do the eUnset.
So if the attribute/EReference was unsettable=true, and if the 'Default
Literal Value' was not specified pressing the Restore default value
button in the properties view, will set the value to 'unset'?

if the attribute/EReference was unsettable=false, and if the 'Default
Literal Value' was not specified will pressing the Restore default value
button in the properties view, set the (attribute/reference) value to null?



>>
>> Is there a consensus how to do this?
> I suppose another special value...
to be handled in the UpdateValueStrategy?

So...

When building the choices list for the comboViewer, I can't use a null,
so I will have to designate an object to act as a null in the
comboViewer choice lists. A blank String seems to work good.

EMFUpdateValueStrategy currently is only detecting Strings and
EAttributes as fromType and toType args in the

IConverter createConverter(Object fromType, Object toType).

Since I am dealing with EReferences here, I will have to subclass
EMFUpdateValueStrategy and override createConverter detecting and
converting EReferences and String.

Sound right?

thanks for the help,
John
>>
>> thanks,
>> John
>>
>>
>>
>>
>> Ed Merks wrote:
>>> Boris,
>>>
>>> ItemPropertyDescriptor.getReachableObjectsOfType is a static utility
>>> that does this type of thing. Basically walking the entire reachable
>>> collection of EObjects for things of a suitable type. As you say,
>>> often it's filtered to satisfy some constraints...
>>>
>>>
>>> Boris Bokowski wrote:
>>>> "John E. Conlon" <jconlon@apache.org> wrote in message
>>>> news:gbje9m$5b3$1@build.eclipse.org...
>>>>
>>>>> I'm trying to create a ComboViewer for an arbitrary EReference but
>>>>> I'm stumped on how to set up the ComboViewer with the EMF databinding.
>>>>>
>>>>> //The main problem is I don't know how to create the initial
>>>>> //IObservableList for the comboViewer
>>>>>
>>>>> IObservableList comboViewerChoices = ??;
>>>>>
>>>>
>>>> If all you have is an object eReference of type EReference, then the
>>>> list of choices would consist of all instances of the EClass
>>>> returned from eReference.getEReferenceType(). I couldn't find a
>>>> method like EClass.getAllInstances() and doubt that such a thing
>>>> exists, so I guess you will have to parameterize your solution so
>>>> that a list of choices can be provided depending on the concrete
>>>> case. Sometimes, any instance will do (e.g., pick any country); but
>>>> you could also have constraints that narrow down the choices (e.g.,
>>>> pick one of the official languages of the previously chosen country).
>>>>
>>>> Boris
>>>>
>>>>
>>>
Re: [Databinding] Creating a ComboViewer for an EReference [message #423391 is a reply to message #423389] Mon, 29 September 2008 19:10 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30813
Registered: July 2009
Senior Member
John,

Comments below.


John E. Conlon wrote:
> Ed,
>
> See inline...
>
> Ed Merks wrote:
>> John,
>>
>> Comments below.
>>
>> John E. Conlon wrote:
>>> Ed, Boris
>>>
>>> Currently I am using propertyDescriptor.getChoiceOfValues(object) to
>>> build the list.
>>>
>>> <snip>
>>> List<Object> choices = new ArrayList<Object>();
>>> for (Object object2 : propertyDescriptor.getChoiceOfValues(object)) {
>>> //Viewers dont like nulls
>>> if (object2 != null) {
>>> choices.add(object2);
>>> }
>>> }
>>>
>>> if (choices.isEmpty()) {
>>> return;
>>> }
>>> comboViewer.setContentProvider(new ArrayContentProvider());
>>> comboViewer.setLabelProvider(new
>>> AdapterFactoryLabelProvider(adapterFactory));
>>> comboViewer.setInput(choices.toArray());
>>>
>>> </snip>
>>>
>>> Would ItemPropertyDescriptor.getReachableObjectsOfType have been
>>> better?
>> No, because that's exactly how it's implemented already. :-P
>>>
>>> Although I can create a list, and could turn it into an
>>> ObservableList, I couldn't get it to work with the databinding
>>> contentProvider and labelProvider so...
>> Don't you just build the list each time instead of trying to maintain
>> it dynamically?
>
> Right, the comboViewer and list is being created each time so there is
> no need for an ongoing observation.
>>>
>>> I took the more traditional path and refactored so as not to require
>>> an ObservableList after all for the input to the comboViewer's list
>>> of choices. (Still curious how this could be done with databinding
>>> though.)
>>>
>>> But I do still use databinding to bind the combo selection to the
>>> model element like:
>>>
>>> dataBindingContext.bindValue(
>>> ViewersObservables.observeSingleSelection(comboViewer),
>>> EMFEditObservables.observeValue(
>>> AdapterFactoryEditingDomain
>>> .getEditingDomainFor(eObject),
>>> eObject,
>>> eStructuralFeature),
>>> tToMStrategy,
>>> mToTStrategy
>>> );
>>>
>>>
>>> Now my remaining question has to do with how I can create the
>>> selection list and bindings to enable unsetting of the eObject's
>>> reference?
>> We alway just add null to the list, but for unsettable features,
>> that's not really sufficient, so we rely on the Restore default value
>> button to actually do the eUnset.
> So if the attribute/EReference was unsettable=true, and if the
> 'Default Literal Value' was not specified pressing the Restore default
> value button in the properties view, will set the value to 'unset'?
>
> if the attribute/EReference was unsettable=false, and if the 'Default
> Literal Value' was not specified will pressing the Restore default
> value button in the properties view, set the (attribute/reference)
> value to null?
It always uses the unset value and always calls eUnset. That always has
the effective of changing the value back to the default value, whatever
it may be and always results in the feature being unset afterwards (so
in the unsettable case, results in the set-state being toggled back to
false).
>
>
>
>>>
>>> Is there a consensus how to do this?
>> I suppose another special value...
> to be handled in the UpdateValueStrategy?
>
> So...
>
> When building the choices list for the comboViewer, I can't use a
> null, so I will have to designate an object to act as a null in the
> comboViewer choice lists. A blank String seems to work good.
>
> EMFUpdateValueStrategy currently is only detecting Strings and
> EAttributes as fromType and toType args in the
>
> IConverter createConverter(Object fromType, Object toType).
>
> Since I am dealing with EReferences here, I will have to subclass
> EMFUpdateValueStrategy and override createConverter detecting and
> converting EReferences and String.
>
> Sound right?
Sounds a bit sucky hey. It's like some standard placeholder values to
denote null and unset would be handy... Surely this null issue can't be
unique to EMF. I wonder how that's normally handled. I've asked before
for the case of a string value, what's the "standard way" of
distinguishing null from the zero length string. This must be a totally
common issue, even for entry fields...
>
> thanks for the help,
> John
>>>
>>> thanks,
>>> John
>>>
>>>
>>>
>>>
>>> Ed Merks wrote:
>>>> Boris,
>>>>
>>>> ItemPropertyDescriptor.getReachableObjectsOfType is a static
>>>> utility that does this type of thing. Basically walking the entire
>>>> reachable collection of EObjects for things of a suitable type. As
>>>> you say, often it's filtered to satisfy some constraints...
>>>>
>>>>
>>>> Boris Bokowski wrote:
>>>>> "John E. Conlon" <jconlon@apache.org> wrote in message
>>>>> news:gbje9m$5b3$1@build.eclipse.org...
>>>>>
>>>>>> I'm trying to create a ComboViewer for an arbitrary EReference
>>>>>> but I'm stumped on how to set up the ComboViewer with the EMF
>>>>>> databinding.
>>>>>>
>>>>>> //The main problem is I don't know how to create the initial
>>>>>> //IObservableList for the comboViewer
>>>>>>
>>>>>> IObservableList comboViewerChoices = ??;
>>>>>>
>>>>>
>>>>> If all you have is an object eReference of type EReference, then
>>>>> the list of choices would consist of all instances of the EClass
>>>>> returned from eReference.getEReferenceType(). I couldn't find a
>>>>> method like EClass.getAllInstances() and doubt that such a thing
>>>>> exists, so I guess you will have to parameterize your solution so
>>>>> that a list of choices can be provided depending on the concrete
>>>>> case. Sometimes, any instance will do (e.g., pick any country);
>>>>> but you could also have constraints that narrow down the choices
>>>>> (e.g., pick one of the official languages of the previously chosen
>>>>> country).
>>>>>
>>>>> Boris
>>>>>
>>>>>
>>>>
Re: [Databinding] Creating a ComboViewer for an EReference [message #423400 is a reply to message #423391] Mon, 29 September 2008 21:39 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: jconlon.apache.org

Ed,

> Sounds a bit sucky hey.
Agree.
It's like some standard placeholder values to
> denote null and unset would be handy... Surely this null issue can't be
> unique to EMF. I wonder how that's normally handled. I've asked before
> for the case of a string value, what's the "standard way" of
> distinguishing null from the zero length string. This must be a totally
> common issue, even for entry fields...
How about SQL use of null:
http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Types.html# NULL

John
Ed Merks wrote:
> John,
>
> Comments below.
>
>
> John E. Conlon wrote:
>> Ed,
>>
>> See inline...
>>
>> Ed Merks wrote:
>>> John,
>>>
>>> Comments below.
>>>
>>> John E. Conlon wrote:
>>>> Ed, Boris
>>>>
>>>> Currently I am using propertyDescriptor.getChoiceOfValues(object) to
>>>> build the list.
>>>>
>>>> <snip>
>>>> List<Object> choices = new ArrayList<Object>();
>>>> for (Object object2 : propertyDescriptor.getChoiceOfValues(object)) {
>>>> //Viewers dont like nulls
>>>> if (object2 != null) {
>>>> choices.add(object2);
>>>> }
>>>> }
>>>>
>>>> if (choices.isEmpty()) {
>>>> return;
>>>> }
>>>> comboViewer.setContentProvider(new ArrayContentProvider());
>>>> comboViewer.setLabelProvider(new
>>>> AdapterFactoryLabelProvider(adapterFactory));
>>>> comboViewer.setInput(choices.toArray());
>>>>
>>>> </snip>
>>>>
>>>> Would ItemPropertyDescriptor.getReachableObjectsOfType have been
>>>> better?
>>> No, because that's exactly how it's implemented already. :-P
>>>>
>>>> Although I can create a list, and could turn it into an
>>>> ObservableList, I couldn't get it to work with the databinding
>>>> contentProvider and labelProvider so...
>>> Don't you just build the list each time instead of trying to maintain
>>> it dynamically?
>>
>> Right, the comboViewer and list is being created each time so there is
>> no need for an ongoing observation.
>>>>
>>>> I took the more traditional path and refactored so as not to require
>>>> an ObservableList after all for the input to the comboViewer's list
>>>> of choices. (Still curious how this could be done with databinding
>>>> though.)
>>>>
>>>> But I do still use databinding to bind the combo selection to the
>>>> model element like:
>>>>
>>>> dataBindingContext.bindValue(
>>>> ViewersObservables.observeSingleSelection(comboViewer),
>>>> EMFEditObservables.observeValue(
>>>> AdapterFactoryEditingDomain
>>>> .getEditingDomainFor(eObject),
>>>> eObject,
>>>> eStructuralFeature),
>>>> tToMStrategy,
>>>> mToTStrategy
>>>> );
>>>>
>>>>
>>>> Now my remaining question has to do with how I can create the
>>>> selection list and bindings to enable unsetting of the eObject's
>>>> reference?
>>> We alway just add null to the list, but for unsettable features,
>>> that's not really sufficient, so we rely on the Restore default value
>>> button to actually do the eUnset.
>> So if the attribute/EReference was unsettable=true, and if the
>> 'Default Literal Value' was not specified pressing the Restore default
>> value button in the properties view, will set the value to 'unset'?
>>
>> if the attribute/EReference was unsettable=false, and if the 'Default
>> Literal Value' was not specified will pressing the Restore default
>> value button in the properties view, set the (attribute/reference)
>> value to null?
> It always uses the unset value and always calls eUnset. That always has
> the effective of changing the value back to the default value, whatever
> it may be and always results in the feature being unset afterwards (so
> in the unsettable case, results in the set-state being toggled back to
> false).
>>
>>
>>
>>>>
>>>> Is there a consensus how to do this?
>>> I suppose another special value...
>> to be handled in the UpdateValueStrategy?
>>
>> So...
>>
>> When building the choices list for the comboViewer, I can't use a
>> null, so I will have to designate an object to act as a null in the
>> comboViewer choice lists. A blank String seems to work good.
>>
>> EMFUpdateValueStrategy currently is only detecting Strings and
>> EAttributes as fromType and toType args in the
>>
>> IConverter createConverter(Object fromType, Object toType).
>>
>> Since I am dealing with EReferences here, I will have to subclass
>> EMFUpdateValueStrategy and override createConverter detecting and
>> converting EReferences and String.
>>
>> Sound right?
> Sounds a bit sucky hey. It's like some standard placeholder values to
> denote null and unset would be handy... Surely this null issue can't be
> unique to EMF. I wonder how that's normally handled. I've asked before
> for the case of a string value, what's the "standard way" of
> distinguishing null from the zero length string. This must be a totally
> common issue, even for entry fields...
>>
>> thanks for the help,
>> John
>>>>
>>>> thanks,
>>>> John
>>>>
>>>>
>>>>
>>>>
>>>> Ed Merks wrote:
>>>>> Boris,
>>>>>
>>>>> ItemPropertyDescriptor.getReachableObjectsOfType is a static
>>>>> utility that does this type of thing. Basically walking the entire
>>>>> reachable collection of EObjects for things of a suitable type. As
>>>>> you say, often it's filtered to satisfy some constraints...
>>>>>
>>>>>
>>>>> Boris Bokowski wrote:
>>>>>> "John E. Conlon" <jconlon@apache.org> wrote in message
>>>>>> news:gbje9m$5b3$1@build.eclipse.org...
>>>>>>
>>>>>>> I'm trying to create a ComboViewer for an arbitrary EReference
>>>>>>> but I'm stumped on how to set up the ComboViewer with the EMF
>>>>>>> databinding.
>>>>>>>
>>>>>>> //The main problem is I don't know how to create the initial
>>>>>>> //IObservableList for the comboViewer
>>>>>>>
>>>>>>> IObservableList comboViewerChoices = ??;
>>>>>>>
>>>>>>
>>>>>> If all you have is an object eReference of type EReference, then
>>>>>> the list of choices would consist of all instances of the EClass
>>>>>> returned from eReference.getEReferenceType(). I couldn't find a
>>>>>> method like EClass.getAllInstances() and doubt that such a thing
>>>>>> exists, so I guess you will have to parameterize your solution so
>>>>>> that a list of choices can be provided depending on the concrete
>>>>>> case. Sometimes, any instance will do (e.g., pick any country);
>>>>>> but you could also have constraints that narrow down the choices
>>>>>> (e.g., pick one of the official languages of the previously chosen
>>>>>> country).
>>>>>>
>>>>>> Boris
>>>>>>
>>>>>>
>>>>>
Re: [Databinding] Creating a ComboViewer for an EReference [message #423401 is a reply to message #423400] Mon, 29 September 2008 21:53 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30813
Registered: July 2009
Senior Member
John,

I guess like that, but that's an int. Probably some public static final
instance of EObject would be better. I'd still like to hear from Boris
and Tom about "standard" data binding techniques for dealing with null
verses empty string and more generally for how to deal with unsettable
values. In DOM, for example, you can use getAttributeNS to get an Attr
and you can check getSpecified to see if that was literally present in
the XML or if it's the default value specified in the XML Schema. Round
tripping the literal DOM requires preserving this state information in
addition to the value (just as it does for EMF's unsettable attributes)...


John E. Conlon wrote:
> Ed,
>
>> Sounds a bit sucky hey.
> Agree.
> It's like some standard placeholder values to
>> denote null and unset would be handy... Surely this null issue can't
>> be unique to EMF. I wonder how that's normally handled. I've asked
>> before for the case of a string value, what's the "standard way" of
>> distinguishing null from the zero length string. This must be a
>> totally common issue, even for entry fields...
> How about SQL use of null:
> http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Types.html# NULL
>
> John
> Ed Merks wrote:
>> John,
>>
>> Comments below.
>>
>>
>> John E. Conlon wrote:
>>> Ed,
>>>
>>> See inline...
>>>
>>> Ed Merks wrote:
>>>> John,
>>>>
>>>> Comments below.
>>>>
>>>> John E. Conlon wrote:
>>>>> Ed, Boris
>>>>>
>>>>> Currently I am using propertyDescriptor.getChoiceOfValues(object)
>>>>> to build the list.
>>>>>
>>>>> <snip>
>>>>> List<Object> choices = new ArrayList<Object>();
>>>>> for (Object object2 : propertyDescriptor.getChoiceOfValues(object)) {
>>>>> //Viewers dont like nulls
>>>>> if (object2 != null) {
>>>>> choices.add(object2);
>>>>> }
>>>>> }
>>>>>
>>>>> if (choices.isEmpty()) {
>>>>> return;
>>>>> }
>>>>> comboViewer.setContentProvider(new ArrayContentProvider());
>>>>> comboViewer.setLabelProvider(new
>>>>> AdapterFactoryLabelProvider(adapterFactory));
>>>>> comboViewer.setInput(choices.toArray());
>>>>>
>>>>> </snip>
>>>>>
>>>>> Would ItemPropertyDescriptor.getReachableObjectsOfType have been
>>>>> better?
>>>> No, because that's exactly how it's implemented already. :-P
>>>>>
>>>>> Although I can create a list, and could turn it into an
>>>>> ObservableList, I couldn't get it to work with the databinding
>>>>> contentProvider and labelProvider so...
>>>> Don't you just build the list each time instead of trying to
>>>> maintain it dynamically?
>>>
>>> Right, the comboViewer and list is being created each time so there
>>> is no need for an ongoing observation.
>>>>>
>>>>> I took the more traditional path and refactored so as not to
>>>>> require an ObservableList after all for the input to the
>>>>> comboViewer's list of choices. (Still curious how this could be
>>>>> done with databinding though.)
>>>>>
>>>>> But I do still use databinding to bind the combo selection to the
>>>>> model element like:
>>>>>
>>>>> dataBindingContext.bindValue(
>>>>> ViewersObservables.observeSingleSelection(comboViewer),
>>>>> EMFEditObservables.observeValue(
>>>>> AdapterFactoryEditingDomain
>>>>> .getEditingDomainFor(eObject),
>>>>> eObject,
>>>>> eStructuralFeature),
>>>>> tToMStrategy,
>>>>> mToTStrategy
>>>>> );
>>>>>
>>>>>
>>>>> Now my remaining question has to do with how I can create the
>>>>> selection list and bindings to enable unsetting of the eObject's
>>>>> reference?
>>>> We alway just add null to the list, but for unsettable features,
>>>> that's not really sufficient, so we rely on the Restore default
>>>> value button to actually do the eUnset.
>>> So if the attribute/EReference was unsettable=true, and if the
>>> 'Default Literal Value' was not specified pressing the Restore
>>> default value button in the properties view, will set the value to
>>> 'unset'?
>>>
>>> if the attribute/EReference was unsettable=false, and if the
>>> 'Default Literal Value' was not specified will pressing the Restore
>>> default value button in the properties view, set the
>>> (attribute/reference) value to null?
>> It always uses the unset value and always calls eUnset. That always
>> has the effective of changing the value back to the default value,
>> whatever it may be and always results in the feature being unset
>> afterwards (so in the unsettable case, results in the set-state being
>> toggled back to false).
>>>
>>>
>>>
>>>>>
>>>>> Is there a consensus how to do this?
>>>> I suppose another special value...
>>> to be handled in the UpdateValueStrategy?
>>>
>>> So...
>>>
>>> When building the choices list for the comboViewer, I can't use a
>>> null, so I will have to designate an object to act as a null in the
>>> comboViewer choice lists. A blank String seems to work good.
>>>
>>> EMFUpdateValueStrategy currently is only detecting Strings and
>>> EAttributes as fromType and toType args in the
>>>
>>> IConverter createConverter(Object fromType, Object toType).
>>>
>>> Since I am dealing with EReferences here, I will have to subclass
>>> EMFUpdateValueStrategy and override createConverter detecting and
>>> converting EReferences and String.
>>>
>>> Sound right?
>> Sounds a bit sucky hey. It's like some standard placeholder values
>> to denote null and unset would be handy... Surely this null issue
>> can't be unique to EMF. I wonder how that's normally handled. I've
>> asked before for the case of a string value, what's the "standard
>> way" of distinguishing null from the zero length string. This must
>> be a totally common issue, even for entry fields...
>>>
>>> thanks for the help,
>>> John
>>>>>
>>>>> thanks,
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Ed Merks wrote:
>>>>>> Boris,
>>>>>>
>>>>>> ItemPropertyDescriptor.getReachableObjectsOfType is a static
>>>>>> utility that does this type of thing. Basically walking the
>>>>>> entire reachable collection of EObjects for things of a suitable
>>>>>> type. As you say, often it's filtered to satisfy some
>>>>>> constraints...
>>>>>>
>>>>>>
>>>>>> Boris Bokowski wrote:
>>>>>>> "John E. Conlon" <jconlon@apache.org> wrote in message
>>>>>>> news:gbje9m$5b3$1@build.eclipse.org...
>>>>>>>
>>>>>>>> I'm trying to create a ComboViewer for an arbitrary EReference
>>>>>>>> but I'm stumped on how to set up the ComboViewer with the EMF
>>>>>>>> databinding.
>>>>>>>>
>>>>>>>> //The main problem is I don't know how to create the initial
>>>>>>>> //IObservableList for the comboViewer
>>>>>>>>
>>>>>>>> IObservableList comboViewerChoices = ??;
>>>>>>>>
>>>>>>>
>>>>>>> If all you have is an object eReference of type EReference, then
>>>>>>> the list of choices would consist of all instances of the EClass
>>>>>>> returned from eReference.getEReferenceType(). I couldn't find a
>>>>>>> method like EClass.getAllInstances() and doubt that such a thing
>>>>>>> exists, so I guess you will have to parameterize your solution
>>>>>>> so that a list of choices can be provided depending on the
>>>>>>> concrete case. Sometimes, any instance will do (e.g., pick any
>>>>>>> country); but you could also have constraints that narrow down
>>>>>>> the choices (e.g., pick one of the official languages of the
>>>>>>> previously chosen country).
>>>>>>>
>>>>>>> Boris
>>>>>>>
>>>>>>>
>>>>>>
Re: [Databinding] Creating a ComboViewer for an EReference [message #423402 is a reply to message #423401] Mon, 29 September 2008 22:05 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6518
Registered: July 2009
Senior Member
Hi,

I think the main issue is that JFace-Viewers don't allow NULL values and
that's why one needs to use the Null-Pattern to identify a NULL value.

I don't think that databinding can know if "" has to be interpreted as
NULL or as an empty-String. This is the task of the converter working
between UI and Model because it differs from situation to situation.

I haven't read through the whole thread and only answered Ed's question
on "" vs NULL so if there's more you need to point me to it.

Tom

Ed Merks schrieb:
> John,
>
> I guess like that, but that's an int. Probably some public static final
> instance of EObject would be better. I'd still like to hear from Boris
> and Tom about "standard" data binding techniques for dealing with null
> verses empty string and more generally for how to deal with unsettable
> values. In DOM, for example, you can use getAttributeNS to get an Attr
> and you can check getSpecified to see if that was literally present in
> the XML or if it's the default value specified in the XML Schema. Round
> tripping the literal DOM requires preserving this state information in
> addition to the value (just as it does for EMF's unsettable attributes)...
>
>
> John E. Conlon wrote:
>> Ed,
>>
>>> Sounds a bit sucky hey.
>> Agree.
>> It's like some standard placeholder values to
>>> denote null and unset would be handy... Surely this null issue can't
>>> be unique to EMF. I wonder how that's normally handled. I've asked
>>> before for the case of a string value, what's the "standard way" of
>>> distinguishing null from the zero length string. This must be a
>>> totally common issue, even for entry fields...
>> How about SQL use of null:
>> http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Types.html# NULL
>>
>> John
>> Ed Merks wrote:
>>> John,
>>>
>>> Comments below.
>>>
>>>
>>> John E. Conlon wrote:
>>>> Ed,
>>>>
>>>> See inline...
>>>>
>>>> Ed Merks wrote:
>>>>> John,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> John E. Conlon wrote:
>>>>>> Ed, Boris
>>>>>>
>>>>>> Currently I am using propertyDescriptor.getChoiceOfValues(object)
>>>>>> to build the list.
>>>>>>
>>>>>> <snip>
>>>>>> List<Object> choices = new ArrayList<Object>();
>>>>>> for (Object object2 : propertyDescriptor.getChoiceOfValues(object)) {
>>>>>> //Viewers dont like nulls
>>>>>> if (object2 != null) {
>>>>>> choices.add(object2);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> if (choices.isEmpty()) {
>>>>>> return;
>>>>>> }
>>>>>> comboViewer.setContentProvider(new ArrayContentProvider());
>>>>>> comboViewer.setLabelProvider(new
>>>>>> AdapterFactoryLabelProvider(adapterFactory));
>>>>>> comboViewer.setInput(choices.toArray());
>>>>>>
>>>>>> </snip>
>>>>>>
>>>>>> Would ItemPropertyDescriptor.getReachableObjectsOfType have been
>>>>>> better?
>>>>> No, because that's exactly how it's implemented already. :-P
>>>>>>
>>>>>> Although I can create a list, and could turn it into an
>>>>>> ObservableList, I couldn't get it to work with the databinding
>>>>>> contentProvider and labelProvider so...
>>>>> Don't you just build the list each time instead of trying to
>>>>> maintain it dynamically?
>>>>
>>>> Right, the comboViewer and list is being created each time so there
>>>> is no need for an ongoing observation.
>>>>>>
>>>>>> I took the more traditional path and refactored so as not to
>>>>>> require an ObservableList after all for the input to the
>>>>>> comboViewer's list of choices. (Still curious how this could be
>>>>>> done with databinding though.)
>>>>>>
>>>>>> But I do still use databinding to bind the combo selection to the
>>>>>> model element like:
>>>>>>
>>>>>> dataBindingContext.bindValue(
>>>>>> ViewersObservables.observeSingleSelection(comboViewer),
>>>>>> EMFEditObservables.observeValue(
>>>>>> AdapterFactoryEditingDomain
>>>>>> .getEditingDomainFor(eObject),
>>>>>> eObject,
>>>>>> eStructuralFeature),
>>>>>> tToMStrategy,
>>>>>> mToTStrategy
>>>>>> );
>>>>>>
>>>>>>
>>>>>> Now my remaining question has to do with how I can create the
>>>>>> selection list and bindings to enable unsetting of the eObject's
>>>>>> reference?
>>>>> We alway just add null to the list, but for unsettable features,
>>>>> that's not really sufficient, so we rely on the Restore default
>>>>> value button to actually do the eUnset.
>>>> So if the attribute/EReference was unsettable=true, and if the
>>>> 'Default Literal Value' was not specified pressing the Restore
>>>> default value button in the properties view, will set the value to
>>>> 'unset'?
>>>>
>>>> if the attribute/EReference was unsettable=false, and if the
>>>> 'Default Literal Value' was not specified will pressing the Restore
>>>> default value button in the properties view, set the
>>>> (attribute/reference) value to null?
>>> It always uses the unset value and always calls eUnset. That always
>>> has the effective of changing the value back to the default value,
>>> whatever it may be and always results in the feature being unset
>>> afterwards (so in the unsettable case, results in the set-state being
>>> toggled back to false).
>>>>
>>>>
>>>>
>>>>>>
>>>>>> Is there a consensus how to do this?
>>>>> I suppose another special value...
>>>> to be handled in the UpdateValueStrategy?
>>>>
>>>> So...
>>>>
>>>> When building the choices list for the comboViewer, I can't use a
>>>> null, so I will have to designate an object to act as a null in the
>>>> comboViewer choice lists. A blank String seems to work good.
>>>>
>>>> EMFUpdateValueStrategy currently is only detecting Strings and
>>>> EAttributes as fromType and toType args in the
>>>>
>>>> IConverter createConverter(Object fromType, Object toType).
>>>>
>>>> Since I am dealing with EReferences here, I will have to subclass
>>>> EMFUpdateValueStrategy and override createConverter detecting and
>>>> converting EReferences and String.
>>>>
>>>> Sound right?
>>> Sounds a bit sucky hey. It's like some standard placeholder values
>>> to denote null and unset would be handy... Surely this null issue
>>> can't be unique to EMF. I wonder how that's normally handled. I've
>>> asked before for the case of a string value, what's the "standard
>>> way" of distinguishing null from the zero length string. This must
>>> be a totally common issue, even for entry fields...
>>>>
>>>> thanks for the help,
>>>> John
>>>>>>
>>>>>> thanks,
>>>>>> John
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Ed Merks wrote:
>>>>>>> Boris,
>>>>>>>
>>>>>>> ItemPropertyDescriptor.getReachableObjectsOfType is a static
>>>>>>> utility that does this type of thing. Basically walking the
>>>>>>> entire reachable collection of EObjects for things of a suitable
>>>>>>> type. As you say, often it's filtered to satisfy some
>>>>>>> constraints...
>>>>>>>
>>>>>>>
>>>>>>> Boris Bokowski wrote:
>>>>>>>> "John E. Conlon" <jconlon@apache.org> wrote in message
>>>>>>>> news:gbje9m$5b3$1@build.eclipse.org...
>>>>>>>>
>>>>>>>>> I'm trying to create a ComboViewer for an arbitrary EReference
>>>>>>>>> but I'm stumped on how to set up the ComboViewer with the EMF
>>>>>>>>> databinding.
>>>>>>>>>
>>>>>>>>> //The main problem is I don't know how to create the initial
>>>>>>>>> //IObservableList for the comboViewer
>>>>>>>>>
>>>>>>>>> IObservableList comboViewerChoices = ??;
>>>>>>>>>
>>>>>>>>
>>>>>>>> If all you have is an object eReference of type EReference, then
>>>>>>>> the list of choices would consist of all instances of the EClass
>>>>>>>> returned from eReference.getEReferenceType(). I couldn't find a
>>>>>>>> method like EClass.getAllInstances() and doubt that such a thing
>>>>>>>> exists, so I guess you will have to parameterize your solution
>>>>>>>> so that a list of choices can be provided depending on the
>>>>>>>> concrete case. Sometimes, any instance will do (e.g., pick any
>>>>>>>> country); but you could also have constraints that narrow down
>>>>>>>> the choices (e.g., pick one of the official languages of the
>>>>>>>> previously chosen country).
>>>>>>>>
>>>>>>>> Boris
>>>>>>>>
>>>>>>>>
>>>>>>>


--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
Re: [Databinding] Creating a ComboViewer for an EReference [message #423403 is a reply to message #423402] Mon, 29 September 2008 23:18 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30813
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------000302070005020309070704
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tom,

Comments below.

Tom Schindl wrote:
> Hi,
>
> I think the main issue is that JFace-Viewers don't allow NULL values and
> that's why one needs to use the Null-Pattern to identify a NULL value.
>
Yet all types except primitives allow now, so that's a shortcoming.
> I don't think that databinding can know if "" has to be interpreted as
> NULL or as an empty-String.
Worst of all, is if you need both, rather than either or...
> This is the task of the converter working
> between UI and Model because it differs from situation to situation.
>
What about when you need both. This is a common problem...
> I haven't read through the whole thread and only answered Ed's question
> on "" vs NULL so if there's more you need to point me to it.
>
I know you're busy. :-P

Consider that a string-valued attribute can support null, "", and
"xyz". How can I support all these without doing something special.
Generally all String-valued features need things.

Consider if a stirng-valued attribute supports not only null, "", and
"xyz" but has to distinguish one additional state, that of explicitly
being null, "", "xyz" or implicitly having that value because it's the
default. I.e., in DOM <x a="foo"/> and <x/>, where <xsd:attribute
name="a" default="foo"/>, will both produce x.getA().equals("foo"), but
one is explicit and the other is implicit. At least this is implicit
default verses explicit value is subtle and one could argue needs extra
"affordances" in the UI, but the null verses "" is an issue pretty much
for every String-valued feature...
> Tom
>
> Ed Merks schrieb:
>
>> John,
>>
>> I guess like that, but that's an int. Probably some public static final
>> instance of EObject would be better. I'd still like to hear from Boris
>> and Tom about "standard" data binding techniques for dealing with null
>> verses empty string and more generally for how to deal with unsettable
>> values. In DOM, for example, you can use getAttributeNS to get an Attr
>> and you can check getSpecified to see if that was literally present in
>> the XML or if it's the default value specified in the XML Schema. Round
>> tripping the literal DOM requires preserving this state information in
>> addition to the value (just as it does for EMF's unsettable attributes)...
>>
>>
>> John E. Conlon wrote:
>>
>>> Ed,
>>>
>>>
>>>> Sounds a bit sucky hey.
>>>>
>>> Agree.
>>> It's like some standard placeholder values to
>>>
>>>> denote null and unset would be handy... Surely this null issue can't
>>>> be unique to EMF. I wonder how that's normally handled. I've asked
>>>> before for the case of a string value, what's the "standard way" of
>>>> distinguishing null from the zero length string. This must be a
>>>> totally common issue, even for entry fields...
>>>>
>>> How about SQL use of null:
>>> http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Types.html# NULL
>>>
>>> John
>>> Ed Merks wrote:
>>>
>>>> John,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> John E. Conlon wrote:
>>>>
>>>>> Ed,
>>>>>
>>>>> See inline...
>>>>>
>>>>> Ed Merks wrote:
>>>>>
>>>>>> John,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>> John E. Conlon wrote:
>>>>>>
>>>>>>> Ed, Boris
>>>>>>>
>>>>>>> Currently I am using propertyDescriptor.getChoiceOfValues(object)
>>>>>>> to build the list.
>>>>>>>
>>>>>>> <snip>
>>>>>>> List<Object> choices = new ArrayList<Object>();
>>>>>>> for (Object object2 : propertyDescriptor.getChoiceOfValues(object)) {
>>>>>>> //Viewers dont like nulls
>>>>>>> if (object2 != null) {
>>>>>>> choices.add(object2);
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> if (choices.isEmpty()) {
>>>>>>> return;
>>>>>>> }
>>>>>>> comboViewer.setContentProvider(new ArrayContentProvider());
>>>>>>> comboViewer.setLabelProvider(new
>>>>>>> AdapterFactoryLabelProvider(adapterFactory));
>>>>>>> comboViewer.setInput(choices.toArray());
>>>>>>>
>>>>>>> </snip>
>>>>>>>
>>>>>>> Would ItemPropertyDescriptor.getReachableObjectsOfType have been
>>>>>>> better?
>>>>>>>
>>>>>> No, because that's exactly how it's implemented already. :-P
>>>>>>
>>>>>>> Although I can create a list, and could turn it into an
>>>>>>> ObservableList, I couldn't get it to work with the databinding
>>>>>>> contentProvider and labelProvider so...
>>>>>>>
>>>>>> Don't you just build the list each time instead of trying to
>>>>>> maintain it dynamically?
>>>>>>
>>>>> Right, the comboViewer and list is being created each time so there
>>>>> is no need for an ongoing observation.
>>>>>
>>>>>>> I took the more traditional path and refactored so as not to
>>>>>>> require an ObservableList after all for the input to the
>>>>>>> comboViewer's list of choices. (Still curious how this could be
>>>>>>> done with databinding though.)
>>>>>>>
>>>>>>> But I do still use databinding to bind the combo selection to the
>>>>>>> model element like:
>>>>>>>
>>>>>>> dataBindingContext.bindValue(
>>>>>>> ViewersObservables.observeSingleSelection(comboViewer),
>>>>>>> EMFEditObservables.observeValue(
>>>>>>> AdapterFactoryEditingDomain
>>>>>>> .getEditingDomainFor(eObject),
>>>>>>> eObject,
>>>>>>> eStructuralFeature),
>>>>>>> tToMStrategy,
>>>>>>> mToTStrategy
>>>>>>> );
>>>>>>>
>>>>>>>
>>>>>>> Now my remaining question has to do with how I can create the
>>>>>>> selection list and bindings to enable unsetting of the eObject's
>>>>>>> reference?
>>>>>>>
>>>>>> We alway just add null to the list, but for unsettable features,
>>>>>> that's not really sufficient, so we rely on the Restore default
>>>>>> value button to actually do the eUnset.
>>>>>>
>>>>> So if the attribute/EReference was unsettable=true, and if the
>>>>> 'Default Literal Value' was not specified pressing the Restore
>>>>> default value button in the properties view, will set the value to
>>>>> 'unset'?
>>>>>
>>>>> if the attribute/EReference was unsettable=false, and if the
>>>>> 'Default Literal Value' was not specified will pressing the Restore
>>>>> default value button in the properties view, set the
>>>>> (attribute/reference) value to null?
>>>>>
>>>> It always uses the unset value and always calls eUnset. That always
>>>> has the effective of changing the value back to the default value,
>>>> whatever it may be and always results in the feature being unset
>>>> afterwards (so in the unsettable case, results in the set-state being
>>>> toggled back to false).
>>>>
>>>>>
>>>>>
>>>>>>> Is there a consensus how to do this?
>>>>>>>
>>>>>> I suppose another special value...
>>>>>>
>>>>> to be handled in the UpdateValueStrategy?
>>>>>
>>>>> So...
>>>>>
>>>>> When building the choices list for the comboViewer, I can't use a
>>>>> null, so I will have to designate an object to act as a null in the
>>>>> comboViewer choice lists. A blank String seems to work good.
>>>>>
>>>>> EMFUpdateValueStrategy currently is only detecting Strings and
>>>>> EAttributes as fromType and toType args in the
>>>>>
>>>>> IConverter createConverter(Object fromType, Object toType).
>>>>>
>>>>> Since I am dealing with EReferences here, I will have to subclass
>>>>> EMFUpdateValueStrategy and override createConverter detecting and
>>>>> converting EReferences and String.
>>>>>
>>>>> Sound right?
>>>>>
>>>> Sounds a bit sucky hey. It's like some standard placeholder values
>>>> to denote null and unset would be handy... Surely this null issue
>>>> can't be unique to EMF. I wonder how that's normally handled. I've
>>>> asked before for the case of a string value, what's the "standard
>>>> way" of distinguishing null from the zero length string. This must
>>>> be a totally common issue, even for entry fields...
>>>>
>>>>> thanks for the help,
>>>>> John
>>>>>
>>>>>>> thanks,
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Ed Merks wrote:
>>>>>>>
>>>>>>>> Boris,
>>>>>>>>
>>>>>>>> ItemPropertyDescriptor.getReachableObjectsOfType is a static
>>>>>>>> utility that does this type of thing. Basically walking the
>>>>>>>> entire reachable collection of EObjects for things of a suitable
>>>>>>>> type. As you say, often it's filtered to satisfy some
>>>>>>>> constraints...
>>>>>>>>
>>>>>>>>
>>>>>>>> Boris Bokowski wrote:
>>>>>>>>
>>>>>>>>> "John E. Conlon" <jconlon@apache.org> wrote in message
>>>>>>>>> news:gbje9m$5b3$1@build.eclipse.org...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I'm trying to create a ComboViewer for an arbitrary EReference
>>>>>>>>>> but I'm stumped on how to set up the ComboViewer with the EMF
>>>>>>>>>> databinding.
>>>>>>>>>>
>>>>>>>>>> //The main problem is I don't know how to create the initial
>>>>>>>>>> //IObservableList for the comboViewer
>>>>>>>>>>
>>>>>>>>>> IObservableList comboViewerChoices = ??;
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> If all you have is an object eReference of type EReference, then
>>>>>>>>> the list of choices would consist of all instances of the EClass
>>>>>>>>> returned from eReference.getEReferenceType(). I couldn't find a
>>>>>>>>> method like EClass.getAllInstances() and doubt that such a thing
>>>>>>>>> exists, so I guess you will have to parameterize your solution
>>>>>>>>> so that a list of choices can be provided depending on the
>>>>>>>>> concrete case. Sometimes, any instance will do (e.g., pick any
>>>>>>>>> country); but you could also have constraints that narrow down
>>>>>>>>> the choices (e.g., pick one of the official languages of the
>>>>>>>>> previously chosen country).
>>>>>>>>>
>>>>>>>>> Boris
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>
>
>

--------------000302070005020309070704
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Tom,<br>
<br>
Comments below.<br>
<br>
Tom Schindl wrote:
<blockquote cite="mid:gbrjen$ba7$1@build.eclipse.org" type="cite">
<pre wrap="">Hi,

I think the main issue is that JFace-Viewers don't allow NULL values and
that's why one needs to use the Null-Pattern to identify a NULL value.
</pre>
</blockquote>
Yet all types except primitives allow now, so that's a shortcoming.<br>
<blockquote cite="mid:gbrjen$ba7$1@build.eclipse.org" type="cite">
<pre wrap="">
I don't think that databinding can know if "" has to be interpreted as
NULL or as an empty-String.</pre>
</blockquote>
Worst of all, is if you need both, rather than either or...<br>
<blockquote cite="mid:gbrjen$ba7$1@build.eclipse.org" type="cite">
<pre wrap=""> This is the task of the converter working
between UI and Model because it differs from situation to situation.
</pre>
</blockquote>
What about when you need both.&nbsp; This is a common problem...<br>
<blockquote cite="mid:gbrjen$ba7$1@build.eclipse.org" type="cite">
<pre wrap="">
I haven't read through the whole thread and only answered Ed's question
on "" vs NULL so if there's more you need to point me to it.
</pre>
</blockquote>
I know you're busy. :-P<br>
<br>
Consider that a string-valued attribute can support null, "", and
"xyz".&nbsp; How can I support all these without doing something special.&nbsp;
Generally all String-valued features need things.<br>
<br>
Consider if a stirng-valued attribute supports not only null, "", and
"xyz" but has to distinguish one additional state, that of explicitly
being null, "", "xyz" or implicitly having that value because it's the
default.&nbsp; I.e., in DOM &lt;x a="foo"/&gt; and &lt;x/&gt;, where
&lt;xsd:attribute name="a" default="foo"/&gt;, will both produce
x.getA().equals("foo"), but one is explicit and the other is implicit.&nbsp;
At least this is implicit default verses explicit value is subtle and
one could argue needs extra "affordances" in the UI, but the null
verses "" is an issue pretty much for every String-valued feature...<br>
<blockquote cite="mid:gbrjen$ba7$1@build.eclipse.org" type="cite">
<pre wrap="">
Tom

Ed Merks schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">John,

I guess like that, but that's an int. Probably some public static final
instance of EObject would be better. I'd still like to hear from Boris
and Tom about "standard" data binding techniques for dealing with null
verses empty string and more generally for how to deal with unsettable
values. In DOM, for example, you can use getAttributeNS to get an Attr
and you can check getSpecified to see if that was literally present in
the XML or if it's the default value specified in the XML Schema. Round
tripping the literal DOM requires preserving this state information in
addition to the value (just as it does for EMF's unsettable attributes)...


John E. Conlon wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Ed,

</pre>
<blockquote type="cite">
<pre wrap="">Sounds a bit sucky hey.
</pre>
</blockquote>
<pre wrap="">Agree.
It's like some standard placeholder values to
</pre>
<blockquote type="cite">
<pre wrap="">denote null and unset would be handy... Surely this null issue can't
be unique to EMF. I wonder how that's normally handled. I've asked
before for the case of a string value, what's the "standard way" of
distinguishing null from the zero length string. This must be a
totally common issue, even for entry fields...
</pre>
</blockquote>
<pre wrap="">How about SQL use of null:
<a class="moz-txt-link-freetext" href=" http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Types.html# NULL"> http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Types.html# NULL</a>

John
Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">John,

Comments below.


John E. Conlon wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Ed,

See inline...

Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">John,

Comments below.

John E. Conlon wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Ed, Boris

Currently I am using propertyDescriptor.getChoiceOfValues(object)
to build the list.

&lt;snip&gt;
List&lt;Object&gt; choices = new ArrayList&lt;Object&gt;();
for (Object object2 : propertyDescriptor.getChoiceOfValues(object)) {
//Viewers dont like nulls
if (object2 != null) {
choices.add(object2);
}
}

if (choices.isEmpty()) {
return;
}
comboViewer.setContentProvider(new ArrayContentProvider());
comboViewer.setLabelProvider(new
AdapterFactoryLabelProvider(adapterFactory));
comboViewer.setInput(choices.toArray());

&lt;/snip&gt;

Would ItemPropertyDescriptor.getReachableObjectsOfType have been
better?
</pre>
</blockquote>
<pre wrap="">No, because that's exactly how it's implemented already. :-P
</pre>
<blockquote type="cite">
<pre wrap="">Although I can create a list, and could turn it into an
ObservableList, I couldn't get it to work with the databinding
contentProvider and labelProvider so...
</pre>
</blockquote>
<pre wrap="">Don't you just build the list each time instead of trying to
maintain it dynamically?
</pre>
</blockquote>
<pre wrap="">Right, the comboViewer and list is being created each time so there
is no need for an ongoing observation.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I took the more traditional path and refactored so as not to
require an ObservableList after all for the input to the
comboViewer's list of choices. (Still curious how this could be
done with databinding though.)

But I do still use databinding to bind the combo selection to the
model element like:

dataBindingContext.bindValue(
ViewersObservables.observeSingleSelection(comboViewer),
EMFEditObservables.observeValue(
AdapterFactoryEditingDomain
.getEditingDomainFor(eObject),
eObject,
eStructuralFeature),
tToMStrategy,
mToTStrategy
);


Now my remaining question has to do with how I can create the
selection list and bindings to enable unsetting of the eObject's
reference?
</pre>
</blockquote>
<pre wrap="">We alway just add null to the list, but for unsettable features,
that's not really sufficient, so we rely on the Restore default
value button to actually do the eUnset.
</pre>
</blockquote>
<pre wrap="">So if the attribute/EReference was unsettable=true, and if the
'Default Literal Value' was not specified pressing the Restore
default value button in the properties view, will set the value to
'unset'?

if the attribute/EReference was unsettable=false, and if the
'Default Literal Value' was not specified will pressing the Restore
default value button in the properties view, set the
(attribute/reference) value to null?
</pre>
</blockquote>
<pre wrap="">It always uses the unset value and always calls eUnset. That always
has the effective of changing the value back to the default value,
whatever it may be and always results in the feature being unset
afterwards (so in the unsettable case, results in the set-state being
toggled back to false).
</pre>
<blockquote type="cite">
<pre wrap="">

</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Is there a consensus how to do this?
</pre>
</blockquote>
<pre wrap="">I suppose another special value...
</pre>
</blockquote>
<pre wrap="">to be handled in the UpdateValueStrategy?

So...

When building the choices list for the comboViewer, I can't use a
null, so I will have to designate an object to act as a null in the
comboViewer choice lists. A blank String seems to work good.

EMFUpdateValueStrategy currently is only detecting Strings and
EAttributes as fromType and toType args in the

IConverter createConverter(Object fromType, Object toType).

Since I am dealing with EReferences here, I will have to subclass
EMFUpdateValueStrategy and override createConverter detecting and
converting EReferences and String.

Sound right?
</pre>
</blockquote>
<pre wrap="">Sounds a bit sucky hey. It's like some standard placeholder values
to denote null and unset would be handy... Surely this null issue
can't be unique to EMF. I wonder how that's normally handled. I've
asked before for the case of a string value, what's the "standard
way" of distinguishing null from the zero length string. This must
be a totally common issue, even for entry fields...
</pre>
<blockquote type="cite">
<pre wrap="">thanks for the help,
John
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">thanks,
John




Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Boris,

ItemPropertyDescriptor.getReachableObjectsOfType is a static
utility that does this type of thing. Basically walking the
entire reachable collection of EObjects for things of a suitable
type. As you say, often it's filtered to satisfy some
constraints...


Boris Bokowski wrote:
</pre>
<blockquote type="cite">
<pre wrap="">"John E. Conlon" <a class="moz-txt-link-rfc2396E" href="mailto:jconlon@apache.org">&lt;jconlon@apache.org&gt;</a> wrote in message
<a class="moz-txt-link-freetext" href="news:gbje9m$5b3$1@build.eclipse.org">news:gbje9m$5b3$1@build.eclipse.org</a>...

</pre>
<blockquote type="cite">
<pre wrap="">I'm trying to create a ComboViewer for an arbitrary EReference
but I'm stumped on how to set up the ComboViewer with the EMF
databinding.

//The main problem is I don't know how to create the initial
//IObservableList for the comboViewer

IObservableList comboViewerChoices = ??;

</pre>
</blockquote>
<pre wrap="">If all you have is an object eReference of type EReference, then
the list of choices would consist of all instances of the EClass
returned from eReference.getEReferenceType(). I couldn't find a
method like EClass.getAllInstances() and doubt that such a thing
exists, so I guess you will have to parameterize your solution
so that a list of choices can be provided depending on the
concrete case. Sometimes, any instance will do (e.g., pick any
country); but you could also have constraints that narrow down
the choices (e.g., pick one of the official languages of the
previously chosen country).

Boris


</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->

</pre>
</blockquote>
</body>
</html>

--------------000302070005020309070704--
Re: [Databinding] Creating a ComboViewer for an EReference [message #423404 is a reply to message #423403] Mon, 29 September 2008 23:41 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6518
Registered: July 2009
Senior Member
Ed Merks schrieb:
> Tom,
>
> Comments below.
>
> Tom Schindl wrote:
>> Hi,
>>
>> I think the main issue is that JFace-Viewers don't allow NULL values and
>> that's why one needs to use the Null-Pattern to identify a NULL value.
>>
> Yet all types except primitives allow now, so that's a shortcoming.

It's a question of how the internals of JFace-Viewers are working and we
can't change this (e.g. the viewer code creates a HashTable to quickly
find TableItem/TreeItems, doing sorting, ... )

>> I don't think that databinding can know if "" has to be interpreted as
>> NULL or as an empty-String.
> Worst of all, is if you need both, rather than either or...

As said if you bind it you'll need to pass a Converter to your
UpdateStrategy which knows what to do. EMF has all META-Data on board so
it could maybe internally make the appropriate decision what the
String-Value needs converted to. The main databinding modules e.g. when
we have a JavaBean doesn't provide us with this meta-data.

>> This is the task of the converter working
>> between UI and Model because it differs from situation to situation.
>>
> What about when you need both. This is a common problem...

From Databinding point of view you need set a converter which knows to
do the right thing (as said maybe EMF can insert a default one in
EMFDatabindingContext#bind*() because it can query the Metadata available).

>> I haven't read through the whole thread and only answered Ed's question
>> on "" vs NULL so if there's more you need to point me to it.
>>
> I know you're busy. :-P
>
> Consider that a string-valued attribute can support null, "", and
> "xyz". How can I support all these without doing something special.
> Generally all String-valued features need things.
>
> Consider if a stirng-valued attribute supports not only null, "", and
> "xyz" but has to distinguish one additional state, that of explicitly
> being null, "", "xyz" or implicitly having that value because it's the
> default. I.e., in DOM <x a="foo"/> and <x/>, where <xsd:attribute
> name="a" default="foo"/>, will both produce x.getA().equals("foo"), but
> one is explicit and the other is implicit. At least this is implicit
> default verses explicit value is subtle and one could argue needs extra
> "affordances" in the UI, but the null verses "" is an issue pretty much
> for every String-valued feature...

The question is how to display the values in the UI? If you use a
Text-Widget you are lost because it always has "" and doesn't allow to
us to have "null". So the only chance in case of Text is to have a
Context-Menu allowing to set the bound value to:
- null
- default

So it boils down to the question which UI element you want to use.

Tom

--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
Re: [Databinding] Creating a ComboViewer for an EReference [message #423411 is a reply to message #423404] Tue, 30 September 2008 08:40 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30813
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------010504010901040308040107
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tom,

Comments below.

Tom Schindl wrote:
> Ed Merks schrieb:
>
>> Tom,
>>
>> Comments below.
>>
>> Tom Schindl wrote:
>>
>>> Hi,
>>>
>>> I think the main issue is that JFace-Viewers don't allow NULL values and
>>> that's why one needs to use the Null-Pattern to identify a NULL value.
>>>
>>>
>> Yet all types except primitives allow now, so that's a shortcoming.
>>
>
> It's a question of how the internals of JFace-Viewers are working and we
> can't change this (e.g. the viewer code creates a HashTable to quickly
> find TableItem/TreeItems, doing sorting, ... )
>
Yes, just as a text widget don't directly represent null...
>
>>> I don't think that databinding can know if "" has to be interpreted as
>>> NULL or as an empty-String.
>>>
>> Worst of all, is if you need both, rather than either or...
>>
>
> As said if you bind it you'll need to pass a Converter to your
> UpdateStrategy which knows what to do. EMF has all META-Data on board so
> it could maybe internally make the appropriate decision what the
> String-Value needs converted to. The main databinding modules e.g. when
> we have a JavaBean doesn't provide us with this meta-data.
>
The problem ends up being one of encoding null. If one possible string
value has to represent the null value, then whatever string value that
is, you'd need some other way to represent that. And of course, given
that this is a ubiquitous issue, doing it in the same way everywhere is
a concern...
>
>>> This is the task of the converter working
>>> between UI and Model because it differs from situation to situation.
>>>
>>>
>> What about when you need both. This is a common problem...
>>
>
> From Databinding point of view you need set a converter which knows to
> do the right thing (as said maybe EMF can insert a default one in
> EMFDatabindingContext#bind*() because it can query the Metadata available).
>
There's definitely potential for doing it "right" once in the framework...
>
>>> I haven't read through the whole thread and only answered Ed's question
>>> on "" vs NULL so if there's more you need to point me to it.
>>>
>>>
>> I know you're busy. :-P
>>
>> Consider that a string-valued attribute can support null, "", and
>> "xyz". How can I support all these without doing something special.
>> Generally all String-valued features need things.
>>
>> Consider if a stirng-valued attribute supports not only null, "", and
>> "xyz" but has to distinguish one additional state, that of explicitly
>> being null, "", "xyz" or implicitly having that value because it's the
>> default. I.e., in DOM <x a="foo"/> and <x/>, where <xsd:attribute
>> name="a" default="foo"/>, will both produce x.getA().equals("foo"), but
>> one is explicit and the other is implicit. At least this is implicit
>> default verses explicit value is subtle and one could argue needs extra
>> "affordances" in the UI, but the null verses "" is an issue pretty much
>> for every String-valued feature...
>>
>
> The question is how to display the values in the UI? If you use a
> Text-Widget you are lost because it always has "" and doesn't allow to
> us to have "null". So the only chance in case of Text is to have a
> Context-Menu allowing to set the bound value to:
> - null
> - default
>
That's an interesting idea I hadn't considered! It seems to me in the
past that someone suggested a specialized composite widget that included
some type of boolean indicator one could toggle. But with a popup
action and perhaps some type of font style/color feedback, that might
not be necessary.
> So it boils down to the question which UI element you want to use.
>
Exactly. Which UI element to use and how to use it to convey the
details. It would be nice if the core data binding framework would help
with direct support for testing, controlling, and manipulating
isSet/getSpecified/isDefault on properties. The lack of such a concept
in Java beans leads to this being overlooked (e.g., it's next to
impossible to solve this well in the properties view) but in XML and EMF
the concept is important and I'd like to solve it well once and for
all. I'll try to get a chance to talk with you and Boris about possible
approaches. I'm happy to do any and all of the associated work to
arrive at a solution...
> Tom
>
>

--------------010504010901040308040107
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Tom,<br>
<br>
Comments below.<br>
<br>
Tom Schindl wrote:
<blockquote cite="mid:gbrp38$co$1@build.eclipse.org" type="cite">
<pre wrap="">Ed Merks schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">Tom,

Comments below.

Tom Schindl wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,

I think the main issue is that JFace-Viewers don't allow NULL values and
that's why one needs to use the Null-Pattern to identify a NULL value.

</pre>
</blockquote>
<pre wrap="">Yet all types except primitives allow now, so that's a shortcoming.
</pre>
</blockquote>
<pre wrap=""><!---->
It's a question of how the internals of JFace-Viewers are working and we
can't change this (e.g. the viewer code creates a HashTable to quickly
find TableItem/TreeItems, doing sorting, ... )
</pre>
</blockquote>
Yes, just as a text widget don't directly represent null...<br>
<blockquote cite="mid:gbrp38$co$1@build.eclipse.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I don't think that databinding can know if "" has to be interpreted as
NULL or as an empty-String.
</pre>
</blockquote>
<pre wrap="">Worst of all, is if you need both, rather than either or...
</pre>
</blockquote>
<pre wrap=""><!---->
As said if you bind it you'll need to pass a Converter to your
UpdateStrategy which knows what to do. EMF has all META-Data on board so
it could maybe internally make the appropriate decision what the
String-Value needs converted to. The main databinding modules e.g. when
we have a JavaBean doesn't provide us with this meta-data.
</pre>
</blockquote>
The problem ends up being one of encoding null.&nbsp; If one possible string
value has to represent the null value, then whatever string value that
is, you'd need some other way to represent that.&nbsp; And of course, given
that this is a ubiquitous issue, doing it in the same way everywhere is
a concern...<br>
<blockquote cite="mid:gbrp38$co$1@build.eclipse.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> This is the task of the converter working
between UI and Model because it differs from situation to situation.

</pre>
</blockquote>
<pre wrap="">What about when you need both. This is a common problem...
</pre>
</blockquote>
<pre wrap=""><!---->
From Databinding point of view you need set a converter which knows to
do the right thing (as said maybe EMF can insert a default one in
EMFDatabindingContext#bind*() because it can query the Metadata available).
</pre>
</blockquote>
There's definitely potential for doing it "right" once in the
framework...<br>
<blockquote cite="mid:gbrp38$co$1@build.eclipse.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I haven't read through the whole thread and only answered Ed's question
on "" vs NULL so if there's more you need to point me to it.

</pre>
</blockquote>
<pre wrap="">I know you're busy. :-P

Consider that a string-valued attribute can support null, "", and
"xyz". How can I support all these without doing something special.
Generally all String-valued features need things.

Consider if a stirng-valued attribute supports not only null, "", and
"xyz" but has to distinguish one additional state, that of explicitly
being null, "", "xyz" or implicitly having that value because it's the
default. I.e., in DOM &lt;x a="foo"/&gt; and &lt;x/&gt;, where &lt;xsd:attribute
name="a" default="foo"/&gt;, will both produce x.getA().equals("foo"), but
one is explicit and the other is implicit. At least this is implicit
default verses explicit value is subtle and one could argue needs extra
"affordances" in the UI, but the null verses "" is an issue pretty much
for every String-valued feature...
</pre>
</blockquote>
<pre wrap=""><!---->
The question is how to display the values in the UI? If you use a
Text-Widget you are lost because it always has "" and doesn't allow to
us to have "null". So the only chance in case of Text is to have a
Context-Menu allowing to set the bound value to:
- null
- default
</pre>
</blockquote>
That's an interesting idea I hadn't considered!&nbsp; It seems to me in the
past that someone suggested a specialized composite widget that
included some type of boolean indicator one could toggle.&nbsp; But with a
popup action and perhaps some type of font style/color feedback, that
might not be necessary.<br>
<blockquote cite="mid:gbrp38$co$1@build.eclipse.org" type="cite">
<pre wrap="">
So it boils down to the question which UI element you want to use.
</pre>
</blockquote>
Exactly.&nbsp; Which UI element to use and how to use it to convey the
details.&nbsp; It would be nice if the core data binding framework would
help with direct support for testing, controlling, and manipulating
isSet/getSpecified/isDefault on properties.&nbsp; The lack of such a concept
in Java beans leads to this being overlooked (e.g., it's next to
impossible to solve this well in the properties view) but in XML and
EMF the concept is important and I'd like to solve it well once and for
all.&nbsp; I'll try to get a chance to talk with you and Boris about
possible approaches.&nbsp; I'm happy to do any and all of the associated
work to arrive at a solution...<br>
<blockquote cite="mid:gbrp38$co$1@build.eclipse.org" type="cite">
<pre wrap="">
Tom

</pre>
</blockquote>
</body>
</html>

--------------010504010901040308040107--
Re: [Databinding] Creating a ComboViewer for an EReference [message #423415 is a reply to message #423411] Tue, 30 September 2008 09:12 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6518
Registered: July 2009
Senior Member
I'm back from traveling to today in the evening and are available for
the rest of the week.

Tom

Ed Merks schrieb:
> Tom,
>
> Comments below.
>
> Tom Schindl wrote:
>> Ed Merks schrieb:
>>
>>> Tom,
>>>
>>> Comments below.
>>>
>>> Tom Schindl wrote:
>>>
>>>> Hi,
>>>>
>>>> I think the main issue is that JFace-Viewers don't allow NULL values and
>>>> that's why one needs to use the Null-Pattern to identify a NULL value.
>>>>
>>>>
>>> Yet all types except primitives allow now, so that's a shortcoming.
>>>
>>
>> It's a question of how the internals of JFace-Viewers are working and we
>> can't change this (e.g. the viewer code creates a HashTable to quickly
>> find TableItem/TreeItems, doing sorting, ... )
>>
> Yes, just as a text widget don't directly represent null...
>>
>>>> I don't think that databinding can know if "" has to be interpreted as
>>>> NULL or as an empty-String.
>>>>
>>> Worst of all, is if you need both, rather than either or...
>>>
>>
>> As said if you bind it you'll need to pass a Converter to your
>> UpdateStrategy which knows what to do. EMF has all META-Data on board so
>> it could maybe internally make the appropriate decision what the
>> String-Value needs converted to. The main databinding modules e.g. when
>> we have a JavaBean doesn't provide us with this meta-data.
>>
> The problem ends up being one of encoding null. If one possible string
> value has to represent the null value, then whatever string value that
> is, you'd need some other way to represent that. And of course, given
> that this is a ubiquitous issue, doing it in the same way everywhere is
> a concern...
>>
>>>> This is the task of the converter working
>>>> between UI and Model because it differs from situation to situation.
>>>>
>>>>
>>> What about when you need both. This is a common problem...
>>>
>>
>> From Databinding point of view you need set a converter which knows to
>> do the right thing (as said maybe EMF can insert a default one in
>> EMFDatabindingContext#bind*() because it can query the Metadata available).
>>
> There's definitely potential for doing it "right" once in the framework...
>>
>>>> I haven't read through the whole thread and only answered Ed's question
>>>> on "" vs NULL so if there's more you need to point me to it.
>>>>
>>>>
>>> I know you're busy. :-P
>>>
>>> Consider that a string-valued attribute can support null, "", and
>>> "xyz". How can I support all these without doing something special.
>>> Generally all String-valued features need things.
>>>
>>> Consider if a stirng-valued attribute supports not only null, "", and
>>> "xyz" but has to distinguish one additional state, that of explicitly
>>> being null, "", "xyz" or implicitly having that value because it's the
>>> default. I.e., in DOM <x a="foo"/> and <x/>, where <xsd:attribute
>>> name="a" default="foo"/>, will both produce x.getA().equals("foo"), but
>>> one is explicit and the other is implicit. At least this is implicit
>>> default verses explicit value is subtle and one could argue needs extra
>>> "affordances" in the UI, but the null verses "" is an issue pretty much
>>> for every String-valued feature...
>>>
>>
>> The question is how to display the values in the UI? If you use a
>> Text-Widget you are lost because it always has "" and doesn't allow to
>> us to have "null". So the only chance in case of Text is to have a
>> Context-Menu allowing to set the bound value to:
>> - null
>> - default
>>
> That's an interesting idea I hadn't considered! It seems to me in the
> past that someone suggested a specialized composite widget that included
> some type of boolean indicator one could toggle. But with a popup
> action and perhaps some type of font style/color feedback, that might
> not be necessary.
>> So it boils down to the question which UI element you want to use.
>>
> Exactly. Which UI element to use and how to use it to convey the
> details. It would be nice if the core data binding framework would help
> with direct support for testing, controlling, and manipulating
> isSet/getSpecified/isDefault on properties. The lack of such a concept
> in Java beans leads to this being overlooked (e.g., it's next to
> impossible to solve this well in the properties view) but in XML and EMF
> the concept is important and I'd like to solve it well once and for
> all. I'll try to get a chance to talk with you and Boris about possible
> approaches. I'm happy to do any and all of the associated work to
> arrive at a solution...
>> Tom
>>
>>


--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
Re: [Databinding] Creating a ComboViewer for an EReference [message #423427 is a reply to message #423411] Tue, 30 September 2008 13:40 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: jconlon.apache.org

Ed,

Now this is starting to sound very un-sucky B-)

John

Ed Merks wrote:
> Tom,
>
> Comments below.
>
> Tom Schindl wrote:
>> Ed Merks schrieb:
>>
>>> Tom,
>>>
>>> Comments below.
>>>
>>> Tom Schindl wrote:
>>>
>>>> Hi,
>>>>
>>>> I think the main issue is that JFace-Viewers don't allow NULL values
>>>> and
>>>> that's why one needs to use the Null-Pattern to identify a NULL value.
>>>>
>>> Yet all types except primitives allow now, so that's a shortcoming.
>>>
>>
>> It's a question of how the internals of JFace-Viewers are working and we
>> can't change this (e.g. the viewer code creates a HashTable to quickly
>> find TableItem/TreeItems, doing sorting, ... )
>>
> Yes, just as a text widget don't directly represent null...
>>
>>>> I don't think that databinding can know if "" has to be interpreted as
>>>> NULL or as an empty-String.
>>>>
>>> Worst of all, is if you need both, rather than either or...
>>>
>>
>> As said if you bind it you'll need to pass a Converter to your
>> UpdateStrategy which knows what to do. EMF has all META-Data on board so
>> it could maybe internally make the appropriate decision what the
>> String-Value needs converted to. The main databinding modules e.g. when
>> we have a JavaBean doesn't provide us with this meta-data.
>>
> The problem ends up being one of encoding null. If one possible string
> value has to represent the null value, then whatever string value that
> is, you'd need some other way to represent that. And of course, given
> that this is a ubiquitous issue, doing it in the same way everywhere is
> a concern...
>>
>>>> This is the task of the converter working
>>>> between UI and Model because it differs from situation to situation.
>>>>
>>> What about when you need both. This is a common problem...
>>>
>>
>> From Databinding point of view you need set a converter which knows to
>> do the right thing (as said maybe EMF can insert a default one in
>> EMFDatabindingContext#bind*() because it can query the Metadata
>> available).
>>
> There's definitely potential for doing it "right" once in the framework...
>>
>>>> I haven't read through the whole thread and only answered Ed's question
>>>> on "" vs NULL so if there's more you need to point me to it.
>>>>
>>> I know you're busy. :-P
>>>
>>> Consider that a string-valued attribute can support null, "", and
>>> "xyz". How can I support all these without doing something special.
>>> Generally all String-valued features need things.
>>>
>>> Consider if a stirng-valued attribute supports not only null, "", and
>>> "xyz" but has to distinguish one additional state, that of explicitly
>>> being null, "", "xyz" or implicitly having that value because it's the
>>> default. I.e., in DOM <x a="foo"/> and <x/>, where <xsd:attribute
>>> name="a" default="foo"/>, will both produce x.getA().equals("foo"), but
>>> one is explicit and the other is implicit. At least this is implicit
>>> default verses explicit value is subtle and one could argue needs extra
>>> "affordances" in the UI, but the null verses "" is an issue pretty much
>>> for every String-valued feature...
>>>
>>
>> The question is how to display the values in the UI? If you use a
>> Text-Widget you are lost because it always has "" and doesn't allow to
>> us to have "null". So the only chance in case of Text is to have a
>> Context-Menu allowing to set the bound value to:
>> - null
>> - default
>>
> That's an interesting idea I hadn't considered! It seems to me in the
> past that someone suggested a specialized composite widget that included
> some type of boolean indicator one could toggle. But with a popup
> action and perhaps some type of font style/color feedback, that might
> not be necessary.
>> So it boils down to the question which UI element you want to use.
>>
> Exactly. Which UI element to use and how to use it to convey the
> details. It would be nice if the core data binding framework would help
> with direct support for testing, controlling, and manipulating
> isSet/getSpecified/isDefault on properties. The lack of such a concept
> in Java beans leads to this being overlooked (e.g., it's next to
> impossible to solve this well in the properties view) but in XML and EMF
> the concept is important and I'd like to solve it well once and for
> all. I'll try to get a chance to talk with you and Boris about possible
> approaches. I'm happy to do any and all of the associated work to
> arrive at a solution...
>> Tom
>>
>>
>
Re: [Databinding] Creating a ComboViewer for an EReference [message #423496 is a reply to message #423411] Wed, 01 October 2008 13:08 Go to previous message
Hallvard Traetteberg is currently offline Hallvard TraettebergFriend
Messages: 671
Registered: July 2009
Location: Trondheim, Norway
Senior Member
Hi,

Interesting thread, this is :-) These subtle issues are usually forgotten or
overlooked, but are of real importance!

I'm working on a UI modelling tool, which is scriptable using Javascript. In
this context values are wrapped, so I can use Javascript's 'undefined' or
similar. One problem is defining how such values are propagated, e.g. to clear
the selection and details view in a master-detail view. Another is, as already
identified, that the end-user cannot unset a value using the standard widgets.

>> The question is how to display the values in the UI? If you use a
>> Text-Widget you are lost because it always has "" and doesn't allow to
>> us to have "null". So the only chance in case of Text is to have a
>> Context-Menu allowing to set the bound value to:
>> - null
>> - default
>>
> That's an interesting idea I hadn't considered! It seems to me in the
> past that someone suggested a specialized composite widget that included
> some type of boolean indicator one could toggle. But with a popup
> action and perhaps some type of font style/color feedback, that might
> not be necessary.

Perhaps it would be possible to use some kind of "overlay" trick, e.g. a
combination of MouseListener, PaintListener (and drawing), tooltip, cursor, etc.
to create the context menu and state indicator outside the actual widget, so
that the widget needn't actually be changed? The menu would somehow set the
state of the Observable in addition to the widget itself.

Hallvard
Previous Topic:[EMF] privileges for user and modification management
Next Topic:[CDO] O-R mapping
Goto Forum:
  


Current Time: Thu Jan 23 02:35:09 GMT 2020

Powered by FUDForum. Page generated in 0.03823 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top