Home » Eclipse Projects » Eclipse Platform » [Databinding] ObservableListContentProvider for TreeViewers?
| [Databinding] ObservableListContentProvider for TreeViewers? [message #327738] |
Tue, 29 April 2008 21:04  |
Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
I'm using ObservableListContentProvider quite a bit for List and Table
viewers, but I'd like to have something similar for a TreeViewer.
Basically, what I really want is a ITreeContentProvider that manages an
IObservableSet that I can then pass to EMFObservables.observeMaps().
In the end, I'm after a label provider for my TreeViewer that behaves
like ObservableMapLabelProvider to automatically update the tree node
labels as the model changes.
Is there another path that I am missing? I looked through the snippets
but didn't find anything that demonstrates a TreeViewer with data binding.
Thanks in advance,
Eric
|
|
|
| Re: [Databinding] ObservableListContentProvider for TreeViewers? [message #327739 is a reply to message #327738] |
Wed, 30 April 2008 00:02  |
 Matthew Hall
Messages: 368
Registered: July 2009 |
Senior Member |
|
|
Eric,
ObservableListTreeContentProvider and ObservableSetTreeContentProvider
landed in 3.4M6, and they take care of the known elements set just like
the existing content providers. The basic usage for these new providers
is to pass an IObservableFactory to the constructor. The
IObservableFactory is responsible for creating an observable collection
of the children of the passed in element. e.g.
ObservableListTreeContentProvider cp =
new ObservableListTreeContentProvider(BeansObservables.listFacto ry(
realm, "children", MyBean.class));
Any IObservableFactory will do as long as it produces the correct type
of collection for the content provider you use. You could just as
easily use EMFObservables.listFactory(Realm, EStructuralFeature) for
example.
Both tree content providers have a getKnownElements() method just like
Observable(List|Set)ContentProvider so the label provider code should be
pretty much the same:
IObservableMap[] labelMape = BeansObservables.observeMaps(
cp.getKnownElements(),
new String[] { "name", "address", "phone" } );
viewer.setLabelProvider(new ObservableMapLabelProvider(labelMaps));
You may want to take a look at Snippet019TreeViewerWithListFactory.java
in the databinding examples plugin.
Matthew
Eric Rizzo wrote:
> I'm using ObservableListContentProvider quite a bit for List and Table
> viewers, but I'd like to have something similar for a TreeViewer.
> Basically, what I really want is a ITreeContentProvider that manages an
> IObservableSet that I can then pass to EMFObservables.observeMaps().
>
> In the end, I'm after a label provider for my TreeViewer that behaves
> like ObservableMapLabelProvider to automatically update the tree node
> labels as the model changes.
>
> Is there another path that I am missing? I looked through the snippets
> but didn't find anything that demonstrates a TreeViewer with data binding.
>
> Thanks in advance,
> Eric
|
|
|
| Re: [Databinding] ObservableListContentProvider for TreeViewers? [message #327740 is a reply to message #327739] |
Wed, 30 April 2008 00:40 |
Matthew Hall
Messages: 368
Registered: July 2009 |
Senior Member |
|
|
One more detail: ObservableListTreeContentProvider and
ObservableSetTreeContentProvider have two constructor arguments, not
one. The second is a TreeStructureAdvisor, and may be null. Thus:
ObservableListTreeContentProvider cp =
new ObservableListTreeContentProvider(
BeansObservables.listFactory(realm, "children", MyBean.class),
null);
Matthew
Matthew Hall wrote:
> Eric,
>
> ObservableListTreeContentProvider and ObservableSetTreeContentProvider
> landed in 3.4M6, and they take care of the known elements set just like
> the existing content providers. The basic usage for these new providers
> is to pass an IObservableFactory to the constructor. The
> IObservableFactory is responsible for creating an observable collection
> of the children of the passed in element. e.g.
>
> ObservableListTreeContentProvider cp =
> new ObservableListTreeContentProvider(BeansObservables.listFacto ry(
> realm, "children", MyBean.class));
>
> Any IObservableFactory will do as long as it produces the correct type
> of collection for the content provider you use. You could just as
> easily use EMFObservables.listFactory(Realm, EStructuralFeature) for
> example.
>
> Both tree content providers have a getKnownElements() method just like
> Observable(List|Set)ContentProvider so the label provider code should be
> pretty much the same:
>
> IObservableMap[] labelMape = BeansObservables.observeMaps(
> cp.getKnownElements(),
> new String[] { "name", "address", "phone" } );
> viewer.setLabelProvider(new ObservableMapLabelProvider(labelMaps));
>
> You may want to take a look at Snippet019TreeViewerWithListFactory.java
> in the databinding examples plugin.
>
> Matthew
>
> Eric Rizzo wrote:
>> I'm using ObservableListContentProvider quite a bit for List and Table
>> viewers, but I'd like to have something similar for a TreeViewer.
>> Basically, what I really want is a ITreeContentProvider that manages
>> an IObservableSet that I can then pass to EMFObservables.observeMaps().
>>
>> In the end, I'm after a label provider for my TreeViewer that behaves
>> like ObservableMapLabelProvider to automatically update the tree node
>> labels as the model changes.
>>
>> Is there another path that I am missing? I looked through the snippets
>> but didn't find anything that demonstrates a TreeViewer with data
>> binding.
>>
>> Thanks in advance,
>> Eric
|
|
|
| Re: [Databinding] ObservableListContentProvider for TreeViewers? [message #327755 is a reply to message #327740] |
Wed, 30 April 2008 13:40 |
| Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
Matthew,
Thanks for the pointers. This all looks to be new to 3.4, correct?
Unfortunately, our project will (initially) ship on 3.3, so I have to
find a solution that is backwards compatible. It sounds as if there
would be a lot of stuff to copy from 3.4 in order to make this work in
3.3 - probably too much to be practical. Is that a fair analysis?
Eric
Matthew Hall wrote:
> One more detail: ObservableListTreeContentProvider and
> ObservableSetTreeContentProvider have two constructor arguments, not
> one. The second is a TreeStructureAdvisor, and may be null. Thus:
>
> ObservableListTreeContentProvider cp =
> new ObservableListTreeContentProvider(
> BeansObservables.listFactory(realm, "children", MyBean.class),
> null);
>
> Matthew
>
> Matthew Hall wrote:
>> Eric,
>>
>> ObservableListTreeContentProvider and ObservableSetTreeContentProvider
>> landed in 3.4M6, and they take care of the known elements set just
>> like the existing content providers. The basic usage for these new
>> providers is to pass an IObservableFactory to the constructor. The
>> IObservableFactory is responsible for creating an observable
>> collection of the children of the passed in element. e.g.
>>
>> ObservableListTreeContentProvider cp =
>> new ObservableListTreeContentProvider(BeansObservables.listFacto ry(
>> realm, "children", MyBean.class));
>>
>> Any IObservableFactory will do as long as it produces the correct type
>> of collection for the content provider you use. You could just as
>> easily use EMFObservables.listFactory(Realm, EStructuralFeature) for
>> example.
>>
>> Both tree content providers have a getKnownElements() method just like
>> Observable(List|Set)ContentProvider so the label provider code should
>> be pretty much the same:
>>
>> IObservableMap[] labelMape = BeansObservables.observeMaps(
>> cp.getKnownElements(),
>> new String[] { "name", "address", "phone" } );
>> viewer.setLabelProvider(new ObservableMapLabelProvider(labelMaps));
>>
>> You may want to take a look at
>> Snippet019TreeViewerWithListFactory.java in the databinding examples
>> plugin.
>>
>> Matthew
>>
>> Eric Rizzo wrote:
>>> I'm using ObservableListContentProvider quite a bit for List and
>>> Table viewers, but I'd like to have something similar for a TreeViewer.
>>> Basically, what I really want is a ITreeContentProvider that manages
>>> an IObservableSet that I can then pass to EMFObservables.observeMaps().
>>>
>>> In the end, I'm after a label provider for my TreeViewer that behaves
>>> like ObservableMapLabelProvider to automatically update the tree node
>>> labels as the model changes.
>>>
>>> Is there another path that I am missing? I looked through the
>>> snippets but didn't find anything that demonstrates a TreeViewer with
>>> data binding.
>>>
>>> Thanks in advance,
>>> Eric
|
|
|
| Re: [Databinding] ObservableListContentProvider for TreeViewers? [message #327756 is a reply to message #327755] |
Wed, 30 April 2008 14:12 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Eric Databinding from 3.4 should be compatible with 3.3 so simply
replacing the whole bundle could be the way to go.
Tom
Eric Rizzo schrieb:
> Matthew,
> Thanks for the pointers. This all looks to be new to 3.4, correct?
> Unfortunately, our project will (initially) ship on 3.3, so I have to
> find a solution that is backwards compatible. It sounds as if there
> would be a lot of stuff to copy from 3.4 in order to make this work in
> 3.3 - probably too much to be practical. Is that a fair analysis?
>
> Eric
>
>
> Matthew Hall wrote:
>> One more detail: ObservableListTreeContentProvider and
>> ObservableSetTreeContentProvider have two constructor arguments, not
>> one. The second is a TreeStructureAdvisor, and may be null. Thus:
>>
>> ObservableListTreeContentProvider cp =
>> new ObservableListTreeContentProvider(
>> BeansObservables.listFactory(realm, "children", MyBean.class),
>> null);
>>
>> Matthew
>>
>> Matthew Hall wrote:
>>> Eric,
>>>
>>> ObservableListTreeContentProvider and
>>> ObservableSetTreeContentProvider landed in 3.4M6, and they take care
>>> of the known elements set just like the existing content providers.
>>> The basic usage for these new providers is to pass an
>>> IObservableFactory to the constructor. The IObservableFactory is
>>> responsible for creating an observable collection of the children of
>>> the passed in element. e.g.
>>>
>>> ObservableListTreeContentProvider cp =
>>> new ObservableListTreeContentProvider(BeansObservables.listFacto ry(
>>> realm, "children", MyBean.class));
>>>
>>> Any IObservableFactory will do as long as it produces the correct
>>> type of collection for the content provider you use. You could just
>>> as easily use EMFObservables.listFactory(Realm, EStructuralFeature)
>>> for example.
>>>
>>> Both tree content providers have a getKnownElements() method just
>>> like Observable(List|Set)ContentProvider so the label provider code
>>> should be pretty much the same:
>>>
>>> IObservableMap[] labelMape = BeansObservables.observeMaps(
>>> cp.getKnownElements(),
>>> new String[] { "name", "address", "phone" } );
>>> viewer.setLabelProvider(new ObservableMapLabelProvider(labelMaps));
>>>
>>> You may want to take a look at
>>> Snippet019TreeViewerWithListFactory.java in the databinding examples
>>> plugin.
>>>
>>> Matthew
>>>
>>> Eric Rizzo wrote:
>>>> I'm using ObservableListContentProvider quite a bit for List and
>>>> Table viewers, but I'd like to have something similar for a TreeViewer.
>>>> Basically, what I really want is a ITreeContentProvider that manages
>>>> an IObservableSet that I can then pass to EMFObservables.observeMaps().
>>>>
>>>> In the end, I'm after a label provider for my TreeViewer that
>>>> behaves like ObservableMapLabelProvider to automatically update the
>>>> tree node labels as the model changes.
>>>>
>>>> Is there another path that I am missing? I looked through the
>>>> snippets but didn't find anything that demonstrates a TreeViewer
>>>> with data binding.
>>>>
>>>> Thanks in advance,
>>>> Eric
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
| Re: [Databinding] ObservableListContentProvider for TreeViewers? [message #327767 is a reply to message #327756] |
Wed, 30 April 2008 23:07 |
| Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
Tom Schindl wrote:
> Eric Databinding from 3.4 should be compatible with 3.3 so simply
> replacing the whole bundle could be the way to go.
That's an interesting experiment, for sure. But I'd have to convince The
Powers That Be that the risk is worthwhile, being so close to our
project's RC1 build. It would require extensive regression testing of
all our UI, as we make extensive use of data binding.
So if upgrading to the 3.4 data binding is not an option, is there any
help to make it simpler to roll my own databinding-aware tree content
provider?
Eric
> Eric Rizzo schrieb:
>> Matthew,
>> Thanks for the pointers. This all looks to be new to 3.4, correct?
>> Unfortunately, our project will (initially) ship on 3.3, so I have to
>> find a solution that is backwards compatible. It sounds as if there
>> would be a lot of stuff to copy from 3.4 in order to make this work in
>> 3.3 - probably too much to be practical. Is that a fair analysis?
>>
>> Eric
>>
>>
>> Matthew Hall wrote:
>>> One more detail: ObservableListTreeContentProvider and
>>> ObservableSetTreeContentProvider have two constructor arguments, not
>>> one. The second is a TreeStructureAdvisor, and may be null. Thus:
>>>
>>> ObservableListTreeContentProvider cp =
>>> new ObservableListTreeContentProvider(
>>> BeansObservables.listFactory(realm, "children", MyBean.class),
>>> null);
>>>
>>> Matthew
>>>
>>> Matthew Hall wrote:
>>>> Eric,
>>>>
>>>> ObservableListTreeContentProvider and
>>>> ObservableSetTreeContentProvider landed in 3.4M6, and they take care
>>>> of the known elements set just like the existing content providers.
>>>> The basic usage for these new providers is to pass an
>>>> IObservableFactory to the constructor. The IObservableFactory is
>>>> responsible for creating an observable collection of the children of
>>>> the passed in element. e.g.
>>>>
>>>> ObservableListTreeContentProvider cp =
>>>> new ObservableListTreeContentProvider(BeansObservables.listFacto ry(
>>>> realm, "children", MyBean.class));
>>>>
>>>> Any IObservableFactory will do as long as it produces the correct
>>>> type of collection for the content provider you use. You could just
>>>> as easily use EMFObservables.listFactory(Realm, EStructuralFeature)
>>>> for example.
>>>>
>>>> Both tree content providers have a getKnownElements() method just
>>>> like Observable(List|Set)ContentProvider so the label provider code
>>>> should be pretty much the same:
>>>>
>>>> IObservableMap[] labelMape = BeansObservables.observeMaps(
>>>> cp.getKnownElements(),
>>>> new String[] { "name", "address", "phone" } );
>>>> viewer.setLabelProvider(new ObservableMapLabelProvider(labelMaps));
>>>>
>>>> You may want to take a look at
>>>> Snippet019TreeViewerWithListFactory.java in the databinding examples
>>>> plugin.
>>>>
>>>> Matthew
>>>>
>>>> Eric Rizzo wrote:
>>>>> I'm using ObservableListContentProvider quite a bit for List and
>>>>> Table viewers, but I'd like to have something similar for a
>>>>> TreeViewer.
>>>>> Basically, what I really want is a ITreeContentProvider that
>>>>> manages an IObservableSet that I can then pass to
>>>>> EMFObservables.observeMaps().
>>>>>
>>>>> In the end, I'm after a label provider for my TreeViewer that
>>>>> behaves like ObservableMapLabelProvider to automatically update the
>>>>> tree node labels as the model changes.
>>>>>
>>>>> Is there another path that I am missing? I looked through the
>>>>> snippets but didn't find anything that demonstrates a TreeViewer
>>>>> with data binding.
>>>>>
>>>>> Thanks in advance,
>>>>> Eric
>
>
|
|
|
| Re: [Databinding] ObservableListContentProvider for TreeViewers? [message #327775 is a reply to message #327767] |
Thu, 01 May 2008 00:30 |
Matthew Hall
Messages: 368
Registered: July 2009 |
Senior Member |
|
|
You could just grab the code from CVS head and copy it to your project.
You'll need ObservableCollectionTreeContentProvider,
Observable(List|Set)TreeContentProvider, TreeViewerUpdater,
ObservableViewerElementSet, ViewerElementSet, and ViewerElementMap.
There may be some other dependencies but those are all that come to mind.
Matthew
Eric Rizzo wrote:
> Tom Schindl wrote:
>> Eric Databinding from 3.4 should be compatible with 3.3 so simply
>> replacing the whole bundle could be the way to go.
>
> That's an interesting experiment, for sure. But I'd have to convince The
> Powers That Be that the risk is worthwhile, being so close to our
> project's RC1 build. It would require extensive regression testing of
> all our UI, as we make extensive use of data binding.
>
> So if upgrading to the 3.4 data binding is not an option, is there any
> help to make it simpler to roll my own databinding-aware tree content
> provider?
>
> Eric
>
>
>> Eric Rizzo schrieb:
>>> Matthew,
>>> Thanks for the pointers. This all looks to be new to 3.4, correct?
>>> Unfortunately, our project will (initially) ship on 3.3, so I have to
>>> find a solution that is backwards compatible. It sounds as if there
>>> would be a lot of stuff to copy from 3.4 in order to make this work
>>> in 3.3 - probably too much to be practical. Is that a fair analysis?
>>>
>>> Eric
>>>
>>>
>>> Matthew Hall wrote:
>>>> One more detail: ObservableListTreeContentProvider and
>>>> ObservableSetTreeContentProvider have two constructor arguments, not
>>>> one. The second is a TreeStructureAdvisor, and may be null. Thus:
>>>>
>>>> ObservableListTreeContentProvider cp =
>>>> new ObservableListTreeContentProvider(
>>>> BeansObservables.listFactory(realm, "children", MyBean.class),
>>>> null);
>>>>
>>>> Matthew
>>>>
>>>> Matthew Hall wrote:
>>>>> Eric,
>>>>>
>>>>> ObservableListTreeContentProvider and
>>>>> ObservableSetTreeContentProvider landed in 3.4M6, and they take
>>>>> care of the known elements set just like the existing content
>>>>> providers. The basic usage for these new providers is to pass an
>>>>> IObservableFactory to the constructor. The IObservableFactory is
>>>>> responsible for creating an observable collection of the children
>>>>> of the passed in element. e.g.
>>>>>
>>>>> ObservableListTreeContentProvider cp =
>>>>> new
>>>>> ObservableListTreeContentProvider(BeansObservables.listFacto ry(
>>>>> realm, "children", MyBean.class));
>>>>>
>>>>> Any IObservableFactory will do as long as it produces the correct
>>>>> type of collection for the content provider you use. You could
>>>>> just as easily use EMFObservables.listFactory(Realm,
>>>>> EStructuralFeature) for example.
>>>>>
>>>>> Both tree content providers have a getKnownElements() method just
>>>>> like Observable(List|Set)ContentProvider so the label provider code
>>>>> should be pretty much the same:
>>>>>
>>>>> IObservableMap[] labelMape = BeansObservables.observeMaps(
>>>>> cp.getKnownElements(),
>>>>> new String[] { "name", "address", "phone" } );
>>>>> viewer.setLabelProvider(new ObservableMapLabelProvider(labelMaps));
>>>>>
>>>>> You may want to take a look at
>>>>> Snippet019TreeViewerWithListFactory.java in the databinding
>>>>> examples plugin.
>>>>>
>>>>> Matthew
>>>>>
>>>>> Eric Rizzo wrote:
>>>>>> I'm using ObservableListContentProvider quite a bit for List and
>>>>>> Table viewers, but I'd like to have something similar for a
>>>>>> TreeViewer.
>>>>>> Basically, what I really want is a ITreeContentProvider that
>>>>>> manages an IObservableSet that I can then pass to
>>>>>> EMFObservables.observeMaps().
>>>>>>
>>>>>> In the end, I'm after a label provider for my TreeViewer that
>>>>>> behaves like ObservableMapLabelProvider to automatically update
>>>>>> the tree node labels as the model changes.
>>>>>>
>>>>>> Is there another path that I am missing? I looked through the
>>>>>> snippets but didn't find anything that demonstrates a TreeViewer
>>>>>> with data binding.
>>>>>>
>>>>>> Thanks in advance,
>>>>>> Eric
>>
>>
|
|
|
Goto Forum:
Current Time: Sat Jul 27 20:13:33 GMT 2024
Powered by FUDForum. Page generated in 0.05469 seconds |
] 
Search
Help
Register
Login
Home
