Home » Modeling » EMF » AdapterFactoryTableTreeEditor status
| |
| Re: AdapterFactoryTableTreeEditor status [message #416995 is a reply to message #416968] |
Fri, 22 February 2008 02:01   |
 Jim Steel
Messages: 54
Registered: July 2009 |
Member |
|
|
Hi Ed,
Thanks for the reply - I was afraid you might say that. You're quite
right, that AdapterFactoryTreeEditor seems to be the way to go, but
AdapterFactoryTableTreeEditor had a whole of stuff built in to handle
cells in other columns, that isn't there in the more basic
AdapterFactoryTreeEditor.
For example, I'm struggling at the moment with how to populate the cells
in other columns with TreeItems. Presumably I need to modify the
ItemProvider to create them somehow, but I'm really lost as to where I
do that. Inheriting from ITableItemLabelProvider makes it really easy
for text and image, but there doesn't seem to be an equivalent table
content provider.
Is there an example somewhere of an editor that uses
AdapterFactorTreeEditor in combination with editable columns (chapter 14
of the book is great for column views, but doesn't seem to get into
editing them)?
Cheers,
Jim.
Ed Merks wrote:
> Jim,
>
> The comment about being under construction is a bit misleading (should
> have been deleted)
>
> |/**
> * This base class for implementing {@link org.eclipse.swt.custom.TableTreeEditor}s that
> * delegate to adapters produced by an {@link AdapterFactory}.
> * This API is under construction; please do not use it for anything more than experimentation.
> * @deprecated
> * @see AdapterFactoryTreeEditor
> */
> @Deprecated
> *public class *AdapterFactoryTableTreeEditor *extends *ExtendedTableTreeEditor|
>
>
> But since the JFace TableTreeViewer is deprecated because TreeViewer
> directly supports columns, I don't think you'd need to use this class
> anymore. Doesn't AdapterFactoryTreeEditor do the trick?
>
>
> Jim Steel wrote:
>>
>> Hi,
>>
>> Can anyone tell me what the status is of the apparently
>> deprecated/abandoned/under-development class
>> AdapterFactoryTableTreeEditor?
>>
>> Cheers,
>>
>> Jim.
>
|
|
|
| Re: AdapterFactoryTableTreeEditor status [message #416996 is a reply to message #416995] |
Fri, 22 February 2008 13:11 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Jim,
Comments below.
Jim Steel wrote:
> Hi Ed,
>
> Thanks for the reply - I was afraid you might say that. You're quite
> right, that AdapterFactoryTreeEditor seems to be the way to go, but
> AdapterFactoryTableTreeEditor had a whole of stuff built in to handle
> cells in other columns, that isn't there in the more basic
> AdapterFactoryTreeEditor.
To be honest, I haven't given it any thought at all. I suspect your
right that AdapterFactoryTreeEditor needs some attention to support
columns directly. If you open a bugzilla feature request for this and
help with at least producing some test cases I can work with you to try
to get the necessary support in place for it.
>
> For example, I'm struggling at the moment with how to populate the
> cells in other columns with TreeItems. Presumably I need to modify the
> ItemProvider to create them somehow, but I'm really lost as to where I
> do that. Inheriting from ITableItemLabelProvider makes it really easy
> for text and image, but there doesn't seem to be an equivalent table
> content provider.
I'm not sure what you mean by this. The content provider just
determines the rows in the table while the label providers determine
what's displayed in the columns...
>
> Is there an example somewhere of an editor that uses
> AdapterFactorTreeEditor in combination with editable columns (chapter
> 14 of the book is great for column views, but doesn't seem to get into
> editing them)?
No. The mapping editor is the only one with support like this and it's
using the old deprecated things. As I said above, if you open a
bugzilla request and help with setting up a project to act as a test
case, I'll try to work with you on making it fully functional. I've not
had time to look at https://bugs.eclipse.org/bugs/show_bug.cgi?id=147436
either, but likely that needs attention at the same time.
>
> Cheers,
>
> Jim.
>
>
>
>
> Ed Merks wrote:
>> Jim,
>>
>> The comment about being under construction is a bit misleading
>> (should have been deleted)
>>
>> |/**
>> * This base class for implementing {@link
>> org.eclipse.swt.custom.TableTreeEditor}s that * delegate to
>> adapters produced by an {@link AdapterFactory}.
>> * This API is under construction; please do not use it for
>> anything more than experimentation.
>> * @deprecated * @see AdapterFactoryTreeEditor
>> */
>> @Deprecated
>> *public class *AdapterFactoryTableTreeEditor *extends
>> *ExtendedTableTreeEditor|
>>
>>
>> But since the JFace TableTreeViewer is deprecated because TreeViewer
>> directly supports columns, I don't think you'd need to use this class
>> anymore. Doesn't AdapterFactoryTreeEditor do the trick?
>>
>>
>> Jim Steel wrote:
>>>
>>> Hi,
>>>
>>> Can anyone tell me what the status is of the apparently
>>> deprecated/abandoned/under-development class
>>> AdapterFactoryTableTreeEditor?
>>>
>>> Cheers,
>>>
>>> Jim.
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: AdapterFactoryTableTreeEditor status [message #417078 is a reply to message #416996] |
Tue, 26 February 2008 02:15 |
Jim Steel
Messages: 54
Registered: July 2009 |
Member |
|
|
Ed Merks wrote:
> Jim,
>
> Comments below.
>
> Jim Steel wrote:
>> Hi Ed,
>>
>> Thanks for the reply - I was afraid you might say that. You're quite
>> right, that AdapterFactoryTreeEditor seems to be the way to go, but
>> AdapterFactoryTableTreeEditor had a whole of stuff built in to handle
>> cells in other columns, that isn't there in the more basic
>> AdapterFactoryTreeEditor.
> To be honest, I haven't given it any thought at all. I suspect your
> right that AdapterFactoryTreeEditor needs some attention to support
> columns directly. If you open a bugzilla feature request for this and
> help with at least producing some test cases I can work with you to try
> to get the necessary support in place for it.
I'm happy to do that.
>>
>> For example, I'm struggling at the moment with how to populate the
>> cells in other columns with TreeItems. Presumably I need to modify the
>> ItemProvider to create them somehow, but I'm really lost as to where I
>> do that. Inheriting from ITableItemLabelProvider makes it really easy
>> for text and image, but there doesn't seem to be an equivalent table
>> content provider.
> I'm not sure what you mean by this. The content provider just
> determines the rows in the table while the label providers determine
> what's displayed in the columns...
Yes, the label providers determine what is displayed in the columns - I
have implemented TableLabelItemProvider, and can see all the things I
want to see in the other columns. However, I want to be able to edit the
values. I can do this by associating basic vanilla celleditors with the
columns, but I'd really like to have the celleditors that are
appropriate to the property I'm editing - the celleditors generated by
the PropertyDescriptor. I've been trying to do this using black magic
involving TreeViewer.setCellEditors() and setCellModifiers(), but
unfortunately, I can't seem get the right CellEditors at creation of the
editor (since they depend on having an instantiated ItemProvider).
I kind of figured that the alternative to doing this was to populate the
columns with TreeItems, in the hope that the editors would automagically
be the right ones (likely through calls to TreeEditor.setEditor(control,
item, int)). I figured the path to creating the items would be via a
ContentProvider. The current ITreeItemContentProvider creates TreeItems
for the first
column (the tree), but I need to make it make it create them in the
other columns.
I'm new to the whole framework, so I'll bow to advice on this, but it
seems to me like there might need to be an extension of
ITreeContentProvider (or some interface in that hierarchy) which
provides additional methods "hasColumnChildren()" and
"getColumnChildren()" (alternatively, follow the analogue of
TableLabelProvider and have "getColumnItem(int columnIndex)"). Then, the
class that calls this (best I can tell, currently TreeViewer, so
probably an extension of TreeViewer) needs to pick this up when it does
redraw, etc.
So I've been thinking about two directions of attack:
- no content provider magic, just fiddling with celleditors and
cellmodifiers during creation of the viewer
- content provider changes in order to populate the tree with TreeItems
so that I can then link TreeItems to appropriate editors.
Do either of these seem to be on the right track?
>>
>> Is there an example somewhere of an editor that uses
>> AdapterFactorTreeEditor in combination with editable columns (chapter
>> 14 of the book is great for column views, but doesn't seem to get into
>> editing them)?
> No. The mapping editor is the only one with support like this and it's
> using the old deprecated things. As I said above, if you open a
> bugzilla request and help with setting up a project to act as a test
> case, I'll try to work with you on making it fully functional. I've not
> had time to look at https://bugs.eclipse.org/bugs/show_bug.cgi?id=147436
> either, but likely that needs attention at the same time.
A simple model with a composite pattern and a leafnode class would serve
as a sample model:
abstract class A;
class B extends A {
composite reference a[0..*] : A
}
class C extends A {
attribute val[1] : int
}
With the aim being to have an editor that displays a tree of B/C
instances, and a column which displays editable A.val values.
If this is a useful test case, then I'm happy to work it up as a project
with ecore, .edit, .editor with support for table display (not edit).
Let me know - I'm still a little scared that I'm on entirely the wrong
track. :)
#147436 sounds like it might be the same file (ExtendedTreeEditor or
ExtendedTableEditor), although its a different kind of beast (presumably
about sensible defaults for keyboard listeners or something).
Cheers,
Jim.
>>
>> Cheers,
>>
>> Jim.
>>
>>
>>
>>
>> Ed Merks wrote:
>>> Jim,
>>>
>>> The comment about being under construction is a bit misleading
>>> (should have been deleted)
>>>
>>> |/**
>>> * This base class for implementing {@link
>>> org.eclipse.swt.custom.TableTreeEditor}s that * delegate to
>>> adapters produced by an {@link AdapterFactory}.
>>> * This API is under construction; please do not use it for
>>> anything more than experimentation.
>>> * @deprecated * @see AdapterFactoryTreeEditor
>>> */
>>> @Deprecated
>>> *public class *AdapterFactoryTableTreeEditor *extends
>>> *ExtendedTableTreeEditor|
>>>
>>>
>>> But since the JFace TableTreeViewer is deprecated because TreeViewer
>>> directly supports columns, I don't think you'd need to use this class
>>> anymore. Doesn't AdapterFactoryTreeEditor do the trick?
>>>
>>>
>>> Jim Steel wrote:
>>>>
>>>> Hi,
>>>>
>>>> Can anyone tell me what the status is of the apparently
>>>> deprecated/abandoned/under-development class
>>>> AdapterFactoryTableTreeEditor?
>>>>
>>>> Cheers,
>>>>
>>>> Jim.
>>>
|
|
|
| Re: AdapterFactoryTableTreeEditor status [message #417079 is a reply to message #417078] |
Tue, 26 February 2008 09:23 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Jim Steel schrieb:
> Ed Merks wrote:
>> Jim,
>>
>> Comments below.
>>
>> Jim Steel wrote:
>>> Hi Ed,
>>>
>>> Thanks for the reply - I was afraid you might say that. You're quite
>>> right, that AdapterFactoryTreeEditor seems to be the way to go, but
>>> AdapterFactoryTableTreeEditor had a whole of stuff built in to handle
>>> cells in other columns, that isn't there in the more basic
>>> AdapterFactoryTreeEditor.
>> To be honest, I haven't given it any thought at all. I suspect your
>> right that AdapterFactoryTreeEditor needs some attention to support
>> columns directly. If you open a bugzilla feature request for this and
>> help with at least producing some test cases I can work with you to
>> try to get the necessary support in place for it.
>
> I'm happy to do that.
>
>>>
>>> For example, I'm struggling at the moment with how to populate the
>>> cells in other columns with TreeItems. Presumably I need to modify
>>> the ItemProvider to create them somehow, but I'm really lost as to
>>> where I do that. Inheriting from ITableItemLabelProvider makes it
>>> really easy for text and image, but there doesn't seem to be an
>>> equivalent table content provider.
>> I'm not sure what you mean by this. The content provider just
>> determines the rows in the table while the label providers determine
>> what's displayed in the columns...
>
> Yes, the label providers determine what is displayed in the columns - I
> have implemented TableLabelItemProvider, and can see all the things I
> want to see in the other columns. However, I want to be able to edit the
> values. I can do this by associating basic vanilla celleditors with the
> columns, but I'd really like to have the celleditors that are
> appropriate to the property I'm editing - the celleditors generated by
> the PropertyDescriptor. I've been trying to do this using black magic
> involving TreeViewer.setCellEditors() and setCellModifiers(), but
> unfortunately, I can't seem get the right CellEditors at creation of the
> editor (since they depend on having an instantiated ItemProvider).
>
> I kind of figured that the alternative to doing this was to populate the
> columns with TreeItems, in the hope that the editors would automagically
> be the right ones (likely through calls to TreeEditor.setEditor(control,
> item, int)). I figured the path to creating the items would be via a
> ContentProvider. The current ITreeItemContentProvider creates TreeItems
> for the first
> column (the tree), but I need to make it make it create them in the
> other columns.
>
> I'm new to the whole framework, so I'll bow to advice on this, but it
> seems to me like there might need to be an extension of
> ITreeContentProvider (or some interface in that hierarchy) which
> provides additional methods "hasColumnChildren()" and
> "getColumnChildren()" (alternatively, follow the analogue of
> TableLabelProvider and have "getColumnItem(int columnIndex)"). Then, the
> class that calls this (best I can tell, currently TreeViewer, so
> probably an extension of TreeViewer) needs to pick this up when it does
> redraw, etc.
>
> So I've been thinking about two directions of attack:
> - no content provider magic, just fiddling with celleditors and
> cellmodifiers during creation of the viewer
> - content provider changes in order to populate the tree with TreeItems
> so that I can then link TreeItems to appropriate editors.
>
The new JFace-3.3 API comes to rescue for you :-) Take a look at the
whole new class infrastructure we provide.
- TreeViewerColumn
- ColumnLabelProvider
- EditingSupport
If you look very close to EditingSupport you'll notice the method
getCellEditor(Object). This API has the big advantage that you can
decide which Editor to show base on the object-type in front of you.
If you want to learn about this new JFace-API take a look at
http://wiki.eclipse.org/JFaceSnippets.
Tom
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
| Re: AdapterFactoryTableTreeEditor status [message #417082 is a reply to message #417078] |
Tue, 26 February 2008 12:46 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------050601090404000000070304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Jim,
Comments below.
Jim Steel wrote:
> Ed Merks wrote:
>> Jim,
>>
>> Comments below.
>>
>> Jim Steel wrote:
>>> Hi Ed,
>>>
>>> Thanks for the reply - I was afraid you might say that. You're quite
>>> right, that AdapterFactoryTreeEditor seems to be the way to go, but
>>> AdapterFactoryTableTreeEditor had a whole of stuff built in to
>>> handle cells in other columns, that isn't there in the more basic
>>> AdapterFactoryTreeEditor.
>> To be honest, I haven't given it any thought at all. I suspect your
>> right that AdapterFactoryTreeEditor needs some attention to support
>> columns directly. If you open a bugzilla feature request for this
>> and help with at least producing some test cases I can work with you
>> to try to get the necessary support in place for it.
>
> I'm happy to do that.
>
>>>
>>> For example, I'm struggling at the moment with how to populate the
>>> cells in other columns with TreeItems. Presumably I need to modify
>>> the ItemProvider to create them somehow, but I'm really lost as to
>>> where I do that. Inheriting from ITableItemLabelProvider makes it
>>> really easy for text and image, but there doesn't seem to be an
>>> equivalent table content provider.
>> I'm not sure what you mean by this. The content provider just
>> determines the rows in the table while the label providers determine
>> what's displayed in the columns...
>
> Yes, the label providers determine what is displayed in the columns - I
> have implemented TableLabelItemProvider, and can see all the things I
> want to see in the other columns. However, I want to be able to edit the
> values. I can do this by associating basic vanilla celleditors with
> the columns, but I'd really like to have the celleditors that are
> appropriate to the property I'm editing - the celleditors generated by
> the PropertyDescriptor.
I see. I've not had time to look closely at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=207324 but it sounds related.
> I've been trying to do this using black magic involving
> TreeViewer.setCellEditors() and setCellModifiers(), but unfortunately,
> I can't seem get the right CellEditors at creation of the editor
> (since they depend on having an instantiated ItemProvider).
You could always get at an IItemPropertySource directly given that an
IPropertySource is accessed like this by AdapterFactoryContentProvider:
| *public *IPropertySource getPropertySource(Object object)
{
*if *(object *instanceof *IPropertySource)
{
*return *(IPropertySource)object;
}
*else*
{
IItemPropertySource itemPropertySource =
(IItemPropertySource)
(object *instanceof *EObject && ((EObject)object).eClass() == *null *?
*null *:
adapterFactory.adapt(object, IItemPropertySourceClass));
*return *
itemPropertySource != *null *? createPropertySource(object, itemPropertySource) : *null*;
}
}|
Perhaps we ought to add a convenience method for that to this class...
>
> I kind of figured that the alternative to doing this was to populate
> the columns with TreeItems, in the hope that the editors would
> automagically be the right ones (likely through calls to
> TreeEditor.setEditor(control, item, int)). I figured the path to
> creating the items would be via a ContentProvider. The current
> ITreeItemContentProvider creates TreeItems for the first
> column (the tree), but I need to make it make it create them in the
> other columns.
The content provider control what object each row will show and the
remaining columns are all "views" on the object in the first column...
>
> I'm new to the whole framework, so I'll bow to advice on this, but it
> seems to me like there might need to be an extension of
> ITreeContentProvider (or some interface in that hierarchy) which
> provides additional methods "hasColumnChildren()" and
> "getColumnChildren()" (alternatively, follow the analogue of
> TableLabelProvider and have "getColumnItem(int columnIndex)"). Then, the
> class that calls this (best I can tell, currently TreeViewer, so
> probably an extension of TreeViewer) needs to pick this up when it does
> redraw, etc.
I don't think so. The content provider already determines the objects of
the rows and then the getColumnText/Image determines what's shown in the
column.
>
> So I've been thinking about two directions of attack:
> - no content provider magic, just fiddling with celleditors and
> cellmodifiers during creation of the viewer
Sounds kind of brute force.
> - content provider changes in order to populate the tree with
> TreeItems so that I can then link TreeItems to appropriate editors.
I don't think this is necessary either.
>
>
> Do either of these seem to be on the right track?
Tom's suggestions sound like good ones, but I've not had time to keep up
with all these JFace additions.
>
>>>
>>> Is there an example somewhere of an editor that uses
>>> AdapterFactorTreeEditor in combination with editable columns
>>> (chapter 14 of the book is great for column views, but doesn't seem
>>> to get into editing them)?
>> No. The mapping editor is the only one with support like this and
>> it's using the old deprecated things. As I said above, if you open a
>> bugzilla request and help with setting up a project to act as a test
>> case, I'll try to work with you on making it fully functional. I've
>> not had time to look at
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=147436 either, but
>> likely that needs attention at the same time.
>
> A simple model with a composite pattern and a leafnode class would
> serve as a sample model:
>
> abstract class A;
> class B extends A {
> composite reference a[0..*] : A
> }
> class C extends A {
> attribute val[1] : int
> }
>
> With the aim being to have an editor that displays a tree of B/C
> instances, and a column which displays editable A.val values.
I'll bet that bugzilla I mentioned above does almost exactly this...
>
> If this is a useful test case, then I'm happy to work it up as a
> project with ecore, .edit, .editor with support for table display (not
> edit). Let me know - I'm still a little scared that I'm on entirely
> the wrong track. :)
>
> #147436 sounds like it might be the same file (ExtendedTreeEditor or
> ExtendedTableEditor), although its a different kind of beast
> (presumably about sensible defaults for keyboard listeners or something).
I've not had time to explore that either, but in our mapping editor, we
have a cell editor that acts like a cursor so we can navigate via the
keyboard to any row's column. I think this cursor thing provides that
same support...
>
> Cheers,
>
> Jim.
>
>
>
>>>
>>> Cheers,
>>>
>>> Jim.
>>>
>>>
>>>
>>>
>>> Ed Merks wrote:
>>>> Jim,
>>>>
>>>> The comment about being under construction is a bit misleading
>>>> (should have been deleted)
>>>>
>>>> |/**
>>>> * This base class for implementing {@link
>>>> org.eclipse.swt.custom.TableTreeEditor}s that * delegate to
>>>> adapters produced by an {@link AdapterFactory}.
>>>> * This API is under construction; please do not use it for
>>>> anything more than experimentation.
>>>> * @deprecated * @see AdapterFactoryTreeEditor
>>>> */
>>>> @Deprecated
>>>> *public class *AdapterFactoryTableTreeEditor *extends
>>>> *ExtendedTableTreeEditor|
>>>>
>>>>
>>>> But since the JFace TableTreeViewer is deprecated because
>>>> TreeViewer directly supports columns, I don't think you'd need to
>>>> use this class anymore. Doesn't AdapterFactoryTreeEditor do the
>>>> trick?
>>>>
>>>>
>>>> Jim Steel wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Can anyone tell me what the status is of the apparently
>>>>> deprecated/abandoned/under-development class
>>>>> AdapterFactoryTableTreeEditor?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Jim.
>>>>
>
--------------050601090404000000070304
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">
Jim,<br>
<br>
Comments below.<br>
<br>
Jim Steel wrote:
<blockquote cite="mid:fpvsn8$uuu$1@build.eclipse.org" type="cite">Ed
Merks wrote:
<br>
<blockquote type="cite">Jim,
<br>
<br>
Comments below.
<br>
<br>
Jim Steel wrote:
<br>
<blockquote type="cite">Hi Ed,
<br>
<br>
Thanks for the reply - I was afraid you might say that. You're quite
right, that AdapterFactoryTreeEditor seems to be the way to go, but
AdapterFactoryTableTreeEditor had a whole of stuff built in to handle
cells in other columns, that isn't there in the more basic
AdapterFactoryTreeEditor.
<br>
</blockquote>
To be honest, I haven't given it any thought at all. I suspect your
right that AdapterFactoryTreeEditor needs some attention to support
columns directly. If you open a bugzilla feature request for this and
help with at least producing some test cases I can work with you to try
to get the necessary support in place for it.
<br>
</blockquote>
<br>
I'm happy to do that.
<br>
<br>
<blockquote type="cite">
<blockquote type="cite"><br>
For example, I'm struggling at the moment with how to populate the
cells in other columns with TreeItems. Presumably I need to modify the
ItemProvider to create them somehow, but I'm really lost as to where I
do that. Inheriting from ITableItemLabelProvider makes it really easy
for text and image, but there doesn't seem to be an equivalent table
content provider.
<br>
</blockquote>
I'm not sure what you mean by this. The content provider just
determines the rows in the table while the label providers determine
what's displayed in the columns...
<br>
</blockquote>
<br>
Yes, the label providers determine what is displayed in the columns - I
<br>
have implemented TableLabelItemProvider, and can see all the things I
<br>
want to see in the other columns. However, I want to be able to edit
the
<br>
values. I can do this by associating basic vanilla celleditors with the
columns, but I'd really like to have the celleditors that are
appropriate to the property I'm editing - the celleditors generated by
the PropertyDescriptor.</blockquote>
I see. I've not had time to look closely at <a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=207324">https://bugs.eclipse.org/bugs/show_bug.cgi?id=207324</a>
but it sounds related.<br>
<blockquote cite="mid:fpvsn8$uuu$1@build.eclipse.org" type="cite"> I've
been trying to do this using black magic involving
TreeViewer.setCellEditors() and setCellModifiers(), but unfortunately,
I can't seem get the right CellEditors at creation of the editor (since
they depend on having an instantiated ItemProvider).
<br>
</blockquote>
You could always get at an IItemPropertySource directly given that an
IPropertySource is accessed like this by AdapterFactoryContentProvider:<br>
<blockquote>
<title></title>
<style type="text/css">
<!--code { font-family: Courier New, Courier; font-size: 10pt; margin: 0px; }-->
</style>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<!-- ======================================================== --><!-- = Java Sourcecode to HTML automatically converted code = --><!-- = Java2Html Converter 5.0 [2006-02-26] by Markus Gebhard markus@jave.de = -->
<!-- = Further information: http://www.java2html.de = -->
<div class="java" align="left">
<table bgcolor="#ffffff" border="0" cellpadding="3" cellspacing="0">
<tbody>
<tr>
<!-- start source code --> <td align="left" nowrap="nowrap"
valign="top"> <code><font color="#ffffff"> </font><font
color="#7f0055"><b>public </b></font><font color="#000000">IPropertySource getPropertySource </font><font
color="#000000">(</font><font color="#000000">Object object</font><font
color="#000000">)</font><br>
<font color="#ffffff"> </font><font color="#000000">{</font><br>
<font color="#ffffff"> </font ><font color="#7f0055"><b>if </b></font><font
color="#000000">(</font><font color="#000000">object </font><font
color="#7f0055"><b>instanceof </b></font><font color="#000000">IPropertySource</font><font
color="#000000">)</font><br>
<font color="#ffffff"> </font ><font color="#000000">{</font><br>
<font color="#ffffff"> </font><font color="#7f0055"><b>return </b></font><font
color="#000000">(</font><font color="#000000">IPropertySource</font><font
color="#000000">)</font><font color="#000000">object;</font><br>
<font color="#ffffff"> </font ><font color="#000000">}</font><br>
<font color="#ffffff"> </font ><font color="#7f0055"><b>else</b></font><br>
<font color="#ffffff"> </font ><font color="#000000">{</font><br>
<font color="#ffffff"> </font><font color="#000000">IItemPropertySource itemPropertySource = </font><br>
<font color="#ffffff"> </font><font color="#000000">(</font><font
color="#000000">IItemPropertySource</font><font color="#000000">)</font><br>
<font color="#ffffff"> </font><font color="#000000">(</font><font
color="#000000">object </font><font color="#7f0055"><b>instanceof </b></font><font
color="#000000">EObject && </font><font color="#000000">((</font><font
color="#000000">EObject</font><font color="#000000">)</font><font
color="#000000">object</font><font color="#000000">)</font><font
color="#000000">.eClass</font><font color="#000000">() </font><font
color="#000000">== </font><font color="#7f0055"><b>null </b></font><font
color="#000000">?</font><br>
<font color="#ffffff"> </font><font color="#7f0055"><b>null </b></font><font
color="#000000">:</font><br>
<font color="#ffffff"> </font><font color="#000000">adapterFactory.adapt</font><font
color="#000000">(</font><font color="#000000">object, IItemPropertySourceClass</font ><font
color="#000000">))</font><font color="#000000">;</font><br>
<font color="#ffffff"> </font><br>
<font color="#ffffff"> </font><font color="#7f0055"><b>return </b></font><br>
<font color="#ffffff"> </font><font color="#000000">itemPropertySource != </font ><font
color="#7f0055"><b>null </b></font><font color="#000000">? createPropertySource</font ><font
color="#000000">(</font><font color="#000000">object, itemPropertySource</font ><font
color="#000000">) </font><font color="#000000">: </font><font
color="#7f0055"><b>null</b></font><font color="#000000">;</font><br>
<font color="#ffffff"> </font ><font color="#000000">}</font><br>
<font color="#ffffff"> </font><font color="#000000">}</font></code>
</td>
<!-- end source code --> </tr>
</tbody>
</table>
</div>
</blockquote>
Perhaps we ought to add a convenience method for that to this class...<br>
<div class="java" align="left"><br>
</div>
<blockquote><!-- = END of automatically generated HTML code = -->
<!-- ======================================================== --></blockquote>
<blockquote cite="mid:fpvsn8$uuu$1@build.eclipse.org" type="cite"><br>
I kind of figured that the alternative to doing this was to populate
the columns with TreeItems, in the hope that the editors would
automagically be the right ones (likely through calls to
TreeEditor.setEditor(control, item, int)). I figured the path to
creating the items would be via a ContentProvider. The current
ITreeItemContentProvider creates TreeItems for the first
<br>
column (the tree), but I need to make it make it create them in the
<br>
other columns.
<br>
</blockquote>
The content provider control what object each row will show and the
remaining columns are all "views" on the object in the first column...<br>
<blockquote cite="mid:fpvsn8$uuu$1@build.eclipse.org" type="cite"><br>
I'm new to the whole framework, so I'll bow to advice on this, but it
<br>
seems to me like there might need to be an extension of
<br>
ITreeContentProvider (or some interface in that hierarchy) which
<br>
provides additional methods "hasColumnChildren()" and
<br>
"getColumnChildren()" (alternatively, follow the analogue of
<br>
TableLabelProvider and have "getColumnItem(int columnIndex)"). Then,
the
<br>
class that calls this (best I can tell, currently TreeViewer, so
<br>
probably an extension of TreeViewer) needs to pick this up when it does
<br>
redraw, etc.
<br>
</blockquote>
I don't think so. The content provider already determines the objects
of the rows and then the getColumnText/Image determines what's shown in
the column.<br>
<blockquote cite="mid:fpvsn8$uuu$1@build.eclipse.org" type="cite"><br>
So I've been thinking about two directions of attack:
<br>
- no content provider magic, just fiddling with celleditors and
cellmodifiers during creation of the viewer
<br>
</blockquote>
Sounds kind of brute force.<br>
<blockquote cite="mid:fpvsn8$uuu$1@build.eclipse.org" type="cite">-
content provider changes in order to populate the tree with TreeItems
so that I can then link TreeItems to appropriate editors.</blockquote>
I don't think this is necessary either.<br>
<blockquote cite="mid:fpvsn8$uuu$1@build.eclipse.org" type="cite"><br>
<br>
Do either of these seem to be on the right track?
<br>
</blockquote>
Tom's suggestions sound like good ones, but I've not had time to keep
up with all these JFace additions.<br>
<blockquote cite="mid:fpvsn8$uuu$1@build.eclipse.org" type="cite"><br>
<blockquote type="cite">
<blockquote type="cite"><br>
Is there an example somewhere of an editor that uses
AdapterFactorTreeEditor in combination with editable columns (chapter
14 of the book is great for column views, but doesn't seem to get into
editing them)?
<br>
</blockquote>
No. The mapping editor is the only one with support like this and it's
using the old deprecated things. As I said above, if you open a
bugzilla request and help with setting up a project to act as a test
case, I'll try to work with you on making it fully functional. I've
not had time to look at
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=147436">https://bugs.eclipse.org/bugs/show_bug.cgi?id=147436</a> either, but likely
that needs attention at the same time.
<br>
</blockquote>
<br>
A simple model with a composite pattern and a leafnode class would
serve as a sample model:
<br>
<br>
abstract class A;
<br>
class B extends A {
<br>
composite reference a[0..*] : A
<br>
}
<br>
class C extends A {
<br>
attribute val[1] : int
<br>
}
<br>
<br>
With the aim being to have an editor that displays a tree of B/C
instances, and a column which displays editable A.val values.
<br>
</blockquote>
I'll bet that bugzilla I mentioned above does almost exactly this...<br>
<blockquote cite="mid:fpvsn8$uuu$1@build.eclipse.org" type="cite"><br>
If this is a useful test case, then I'm happy to work it up as a
project with ecore, .edit, .editor with support for table display (not
edit). Let me know - I'm still a little scared that I'm on entirely the
wrong track. :)
<br>
<br>
#147436 sounds like it might be the same file (ExtendedTreeEditor or
ExtendedTableEditor), although its a different kind of beast
(presumably about sensible defaults for keyboard listeners or
something).
<br>
</blockquote>
I've not had time to explore that either, but in our mapping editor, we
have a cell editor that acts like a cursor so we can navigate via the
keyboard to any row's column. I think this cursor thing provides that
same support...<br>
<blockquote cite="mid:fpvsn8$uuu$1@build.eclipse.org" type="cite"><br>
Cheers,
<br>
<br>
Jim.
<br>
<br>
<br>
<br>
<blockquote type="cite">
<blockquote type="cite"><br>
Cheers,
<br>
<br>
Jim.
<br>
<br>
<br>
<br>
<br>
Ed Merks wrote:
<br>
<blockquote type="cite">Jim,
<br>
<br>
The comment about being under construction is a bit misleading (should
have been deleted)
<br>
<br>
|/**
<br>
* This base class for implementing {@link
org.eclipse.swt.custom.TableTreeEditor}s that * delegate to
adapters produced by an {@link AdapterFactory}.
<br>
* This API is under construction; please do not use it for
anything more than experimentation.
<br>
* @deprecated   ; * @see AdapterFactoryTreeEditor
<br>
*/
<br>
@Deprecated
<br>
*public class *AdapterFactoryTableTreeEditor *extends
*ExtendedTableTreeEditor|
<br>
<br>
<br>
But since the JFace TableTreeViewer is deprecated because TreeViewer
directly supports columns, I don't think you'd need to use this class
anymore. Doesn't AdapterFactoryTreeEditor do the trick?
<br>
<br>
<br>
Jim Steel wrote:
<br>
<blockquote type="cite"><br>
Hi,
<br>
<br>
Can anyone tell me what the status is of the apparently
deprecated/abandoned/under-development class
AdapterFactoryTableTreeEditor?
<br>
<br>
Cheers,
<br>
<br>
Jim.
<br>
</blockquote>
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>
--------------050601090404000000070304--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: AdapterFactoryTableTreeEditor status [message #417083 is a reply to message #417079] |
Tue, 26 February 2008 12:49 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Tom,
Comments below.
Tom Schindl wrote:
> Jim Steel schrieb:
>> Ed Merks wrote:
>>> Jim,
>>>
>>> Comments below.
>>>
>>> Jim Steel wrote:
>>>> Hi Ed,
>>>>
>>>> Thanks for the reply - I was afraid you might say that. You're
>>>> quite right, that AdapterFactoryTreeEditor seems to be the way to
>>>> go, but AdapterFactoryTableTreeEditor had a whole of stuff built in
>>>> to handle cells in other columns, that isn't there in the more
>>>> basic AdapterFactoryTreeEditor.
>>> To be honest, I haven't given it any thought at all. I suspect your
>>> right that AdapterFactoryTreeEditor needs some attention to support
>>> columns directly. If you open a bugzilla feature request for this
>>> and help with at least producing some test cases I can work with you
>>> to try to get the necessary support in place for it.
>>
>> I'm happy to do that.
>>
>>>>
>>>> For example, I'm struggling at the moment with how to populate the
>>>> cells in other columns with TreeItems. Presumably I need to modify
>>>> the ItemProvider to create them somehow, but I'm really lost as to
>>>> where I do that. Inheriting from ITableItemLabelProvider makes it
>>>> really easy for text and image, but there doesn't seem to be an
>>>> equivalent table content provider.
>>> I'm not sure what you mean by this. The content provider just
>>> determines the rows in the table while the label providers determine
>>> what's displayed in the columns...
>>
>> Yes, the label providers determine what is displayed in the columns - I
>> have implemented TableLabelItemProvider, and can see all the things I
>> want to see in the other columns. However, I want to be able to edit the
>> values. I can do this by associating basic vanilla celleditors with
>> the columns, but I'd really like to have the celleditors that are
>> appropriate to the property I'm editing - the celleditors generated
>> by the PropertyDescriptor. I've been trying to do this using black
>> magic involving TreeViewer.setCellEditors() and setCellModifiers(),
>> but unfortunately, I can't seem get the right CellEditors at creation
>> of the editor (since they depend on having an instantiated
>> ItemProvider).
>>
>> I kind of figured that the alternative to doing this was to populate
>> the columns with TreeItems, in the hope that the editors would
>> automagically be the right ones (likely through calls to
>> TreeEditor.setEditor(control, item, int)). I figured the path to
>> creating the items would be via a ContentProvider. The current
>> ITreeItemContentProvider creates TreeItems for the first
>> column (the tree), but I need to make it make it create them in the
>> other columns.
>>
>> I'm new to the whole framework, so I'll bow to advice on this, but it
>> seems to me like there might need to be an extension of
>> ITreeContentProvider (or some interface in that hierarchy) which
>> provides additional methods "hasColumnChildren()" and
>> "getColumnChildren()" (alternatively, follow the analogue of
>> TableLabelProvider and have "getColumnItem(int columnIndex)"). Then, the
>> class that calls this (best I can tell, currently TreeViewer, so
>> probably an extension of TreeViewer) needs to pick this up when it does
>> redraw, etc.
>>
>> So I've been thinking about two directions of attack:
>> - no content provider magic, just fiddling with celleditors and
>> cellmodifiers during creation of the viewer
>> - content provider changes in order to populate the tree with
>> TreeItems so that I can then link TreeItems to appropriate editors.
>>
>
> The new JFace-3.3 API comes to rescue for you :-) Take a look at the
> whole new class infrastructure we provide.
>
> - TreeViewerColumn
> - ColumnLabelProvider
I imagine that one way to use this column label provider with EMF's item
providers is that it would know the column index and could delegate to
EMF's item providers support for ITableItemLabelProvider. Does that
make sense?
> - EditingSupport
>
> If you look very close to EditingSupport you'll notice the method
> getCellEditor(Object). This API has the big advantage that you can
> decide which Editor to show base on the object-type in front of you.
EMF's support generally relies on knowing the object of the row, but I
think this will be the object of the cell. Is that right?
>
> If you want to learn about this new JFace-API take a look at
> http://wiki.eclipse.org/JFaceSnippets.
So much to learn and so little time. :-(
> Tom
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: AdapterFactoryTableTreeEditor status [message #417085 is a reply to message #417083] |
Tue, 26 February 2008 13:27 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Ed Merks schrieb:
> Tom,
>
> Comments below.
>
> Tom Schindl wrote:
>> Jim Steel schrieb:
>>> Ed Merks wrote:
>>>> Jim,
>>>>
>>>> Comments below.
>>>>
>>>> Jim Steel wrote:
>>>>> Hi Ed,
>>>>>
>>>>> Thanks for the reply - I was afraid you might say that. You're
>>>>> quite right, that AdapterFactoryTreeEditor seems to be the way to
>>>>> go, but AdapterFactoryTableTreeEditor had a whole of stuff built in
>>>>> to handle cells in other columns, that isn't there in the more
>>>>> basic AdapterFactoryTreeEditor.
>>>> To be honest, I haven't given it any thought at all. I suspect your
>>>> right that AdapterFactoryTreeEditor needs some attention to support
>>>> columns directly. If you open a bugzilla feature request for this
>>>> and help with at least producing some test cases I can work with you
>>>> to try to get the necessary support in place for it.
>>>
>>> I'm happy to do that.
>>>
>>>>>
>>>>> For example, I'm struggling at the moment with how to populate the
>>>>> cells in other columns with TreeItems. Presumably I need to modify
>>>>> the ItemProvider to create them somehow, but I'm really lost as to
>>>>> where I do that. Inheriting from ITableItemLabelProvider makes it
>>>>> really easy for text and image, but there doesn't seem to be an
>>>>> equivalent table content provider.
>>>> I'm not sure what you mean by this. The content provider just
>>>> determines the rows in the table while the label providers determine
>>>> what's displayed in the columns...
>>>
>>> Yes, the label providers determine what is displayed in the columns - I
>>> have implemented TableLabelItemProvider, and can see all the things I
>>> want to see in the other columns. However, I want to be able to edit the
>>> values. I can do this by associating basic vanilla celleditors with
>>> the columns, but I'd really like to have the celleditors that are
>>> appropriate to the property I'm editing - the celleditors generated
>>> by the PropertyDescriptor. I've been trying to do this using black
>>> magic involving TreeViewer.setCellEditors() and setCellModifiers(),
>>> but unfortunately, I can't seem get the right CellEditors at creation
>>> of the editor (since they depend on having an instantiated
>>> ItemProvider).
>>>
>>> I kind of figured that the alternative to doing this was to populate
>>> the columns with TreeItems, in the hope that the editors would
>>> automagically be the right ones (likely through calls to
>>> TreeEditor.setEditor(control, item, int)). I figured the path to
>>> creating the items would be via a ContentProvider. The current
>>> ITreeItemContentProvider creates TreeItems for the first
>>> column (the tree), but I need to make it make it create them in the
>>> other columns.
>>>
>>> I'm new to the whole framework, so I'll bow to advice on this, but it
>>> seems to me like there might need to be an extension of
>>> ITreeContentProvider (or some interface in that hierarchy) which
>>> provides additional methods "hasColumnChildren()" and
>>> "getColumnChildren()" (alternatively, follow the analogue of
>>> TableLabelProvider and have "getColumnItem(int columnIndex)"). Then, the
>>> class that calls this (best I can tell, currently TreeViewer, so
>>> probably an extension of TreeViewer) needs to pick this up when it does
>>> redraw, etc.
>>>
>>> So I've been thinking about two directions of attack:
>>> - no content provider magic, just fiddling with celleditors and
>>> cellmodifiers during creation of the viewer
>>> - content provider changes in order to populate the tree with
>>> TreeItems so that I can then link TreeItems to appropriate editors.
>>>
>>
>> The new JFace-3.3 API comes to rescue for you :-) Take a look at the
>> whole new class infrastructure we provide.
>>
>> - TreeViewerColumn
>> - ColumnLabelProvider
> I imagine that one way to use this column label provider with EMF's item
> providers is that it would know the column index and could delegate to
> EMF's item providers support for ITableItemLabelProvider. Does that
> make sense?
Well JFace internally is completely built upon ColumnLabelProvider (= we
are doing it the other way round mapping ITableLabelProvider internally
to ColumnLabelProviders we attach to Table/TreeViewerColumn-s). See
below for my ideas how EMF generated Viewers could work in future :-)
The same happens to CellModifier and friends to support editing they are
mapped to EditingSupport-Instances.
>> - EditingSupport
>>
>> If you look very close to EditingSupport you'll notice the method
>> getCellEditor(Object). This API has the big advantage that you can
>> decide which Editor to show base on the object-type in front of you.
> EMF's support generally relies on knowing the object of the row, but I
> think this will be the object of the cell. Is that right?
No it's the object of the row. We completely abondon the notion of
indices because a EditingSupport/ColumnLabelProvider is directly
attached to the TableViewerColumn.
The reason is simply reusage of LabelProviders and
EditingSupport-Objects. In former days reusage of CellModifier and
I*LabelProviders wasn't possible. Say in one part of your application
your had:
-------------------------------------
| NAME | BIRTH | STREET |
-------------------------------------
in the other one
---------------------------
| BIRTH | NAME |
---------------------------
and in the last you have
------------------------
| NAME | STREET |
------------------------
With the new API you have to following objects you reuse all over:
--------8<--------
PersonNameLabelProvider extends ColumnLabelProvider
PersonNameEditingSupport extends EditingSupport
PersonBirthLabelProvider extends ColumnLabelProvider
PersonBirthEditingSupport extends EditingSupport
PersonStreetLabelProvider extends ColumnLabelProvider
PersonStreetEditingSupport extends EditingSupport
--------8<--------
Reusable all over ;-)
Infact you could say when going the brute-force way that you could
generated a ColumnLabelProvider / EditingSupport for every attribute
displayed/edited or for general purpose an ColumnLabelProvider /
EditingSupport for every object type in your attribute:
--------8<--------
StringLabelProvider extends ColumnLabelProvider
StringEditingSupport extends EditingSupport
DateLabelProvider extends ColumnLabelProvider
DateEditingSupport extends EditingSupport
--------8<--------
I didn't had time in 3.4 to address generic sorting but if we also
attach this to the ViewerColumn EMF could generate even StandardSorters :-)
Now connect all this with Databinding which is also doable with the 3.3
API and you even get validation, ... .
Tom
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
| Re: AdapterFactoryTableTreeEditor status [message #417087 is a reply to message #417085] |
Tue, 26 February 2008 13:36 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Tom,
Comments below.
Tom Schindl wrote:
> Ed Merks schrieb:
>> Tom,
>>
>> Comments below.
>>
>> Tom Schindl wrote:
>>> Jim Steel schrieb:
>>>> Ed Merks wrote:
>>>>> Jim,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Jim Steel wrote:
>>>>>> Hi Ed,
>>>>>>
>>>>>> Thanks for the reply - I was afraid you might say that. You're
>>>>>> quite right, that AdapterFactoryTreeEditor seems to be the way to
>>>>>> go, but AdapterFactoryTableTreeEditor had a whole of stuff built
>>>>>> in to handle cells in other columns, that isn't there in the more
>>>>>> basic AdapterFactoryTreeEditor.
>>>>> To be honest, I haven't given it any thought at all. I suspect
>>>>> your right that AdapterFactoryTreeEditor needs some attention to
>>>>> support columns directly. If you open a bugzilla feature request
>>>>> for this and help with at least producing some test cases I can
>>>>> work with you to try to get the necessary support in place for it.
>>>>
>>>> I'm happy to do that.
>>>>
>>>>>>
>>>>>> For example, I'm struggling at the moment with how to populate
>>>>>> the cells in other columns with TreeItems. Presumably I need to
>>>>>> modify the ItemProvider to create them somehow, but I'm really
>>>>>> lost as to where I do that. Inheriting from
>>>>>> ITableItemLabelProvider makes it really easy for text and image,
>>>>>> but there doesn't seem to be an equivalent table content provider.
>>>>> I'm not sure what you mean by this. The content provider just
>>>>> determines the rows in the table while the label providers
>>>>> determine what's displayed in the columns...
>>>>
>>>> Yes, the label providers determine what is displayed in the columns
>>>> - I
>>>> have implemented TableLabelItemProvider, and can see all the things I
>>>> want to see in the other columns. However, I want to be able to
>>>> edit the
>>>> values. I can do this by associating basic vanilla celleditors with
>>>> the columns, but I'd really like to have the celleditors that are
>>>> appropriate to the property I'm editing - the celleditors generated
>>>> by the PropertyDescriptor. I've been trying to do this using black
>>>> magic involving TreeViewer.setCellEditors() and setCellModifiers(),
>>>> but unfortunately, I can't seem get the right CellEditors at
>>>> creation of the editor (since they depend on having an instantiated
>>>> ItemProvider).
>>>>
>>>> I kind of figured that the alternative to doing this was to
>>>> populate the columns with TreeItems, in the hope that the editors
>>>> would automagically be the right ones (likely through calls to
>>>> TreeEditor.setEditor(control, item, int)). I figured the path to
>>>> creating the items would be via a ContentProvider. The current
>>>> ITreeItemContentProvider creates TreeItems for the first
>>>> column (the tree), but I need to make it make it create them in the
>>>> other columns.
>>>>
>>>> I'm new to the whole framework, so I'll bow to advice on this, but it
>>>> seems to me like there might need to be an extension of
>>>> ITreeContentProvider (or some interface in that hierarchy) which
>>>> provides additional methods "hasColumnChildren()" and
>>>> "getColumnChildren()" (alternatively, follow the analogue of
>>>> TableLabelProvider and have "getColumnItem(int columnIndex)").
>>>> Then, the
>>>> class that calls this (best I can tell, currently TreeViewer, so
>>>> probably an extension of TreeViewer) needs to pick this up when it
>>>> does
>>>> redraw, etc.
>>>>
>>>> So I've been thinking about two directions of attack:
>>>> - no content provider magic, just fiddling with celleditors and
>>>> cellmodifiers during creation of the viewer
>>>> - content provider changes in order to populate the tree with
>>>> TreeItems so that I can then link TreeItems to appropriate editors.
>>>>
>>>
>>> The new JFace-3.3 API comes to rescue for you :-) Take a look at the
>>> whole new class infrastructure we provide.
>>>
>>> - TreeViewerColumn
>>> - ColumnLabelProvider
>> I imagine that one way to use this column label provider with EMF's
>> item providers is that it would know the column index and could
>> delegate to EMF's item providers support for
>> ITableItemLabelProvider. Does that make sense?
>
> Well JFace internally is completely built upon ColumnLabelProvider (=
> we are doing it the other way round mapping ITableLabelProvider
> internally to ColumnLabelProviders we attach to
> Table/TreeViewerColumn-s). See below for my ideas how EMF generated
> Viewers could work in future :-)
This would seem to imply having a separate set of item providers for
each column, rather than a single one for dealing with the whole table.
Maybe that's okay...
>
> The same happens to CellModifier and friends to support editing they
> are mapped to EditingSupport-Instances.
So the column just knows what aspect of the object it's editing. That
makes sense.
>
>>> - EditingSupport
>>>
>>> If you look very close to EditingSupport you'll notice the method
>>> getCellEditor(Object). This API has the big advantage that you can
>>> decide which Editor to show base on the object-type in front of you.
>> EMF's support generally relies on knowing the object of the row, but
>> I think this will be the object of the cell. Is that right?
>
> No it's the object of the row. We completely abondon the notion of
> indices because a EditingSupport/ColumnLabelProvider is directly
> attached to the TableViewerColumn.
>
> The reason is simply reusage of LabelProviders and
> EditingSupport-Objects. In former days reusage of CellModifier and
> I*LabelProviders wasn't possible. Say in one part of your application
> your had:
>
> -------------------------------------
> | NAME | BIRTH | STREET |
> -------------------------------------
>
> in the other one
> ---------------------------
> | BIRTH | NAME |
> ---------------------------
>
> and in the last you have
> ------------------------
> | NAME | STREET |
> ------------------------
>
>
> With the new API you have to following objects you reuse all over:
>
> --------8<--------
> PersonNameLabelProvider extends ColumnLabelProvider
> PersonNameEditingSupport extends EditingSupport
>
> PersonBirthLabelProvider extends ColumnLabelProvider
> PersonBirthEditingSupport extends EditingSupport
>
> PersonStreetLabelProvider extends ColumnLabelProvider
> PersonStreetEditingSupport extends EditingSupport
> --------8<--------
>
> Reusable all over ;-)
I can still imagine having an item provider that knows about all the
various columns it could support where the column index is just a "key"
rather than really indicating a column number and then having a label
provider that delegates the column labels to the appropriate key. (One
of the nice things about Eclipse is it's ever progressing and improving,
but that also means there are getting to be an awful lot of different
ways to do the same thing.)
>
> Infact you could say when going the brute-force way that you could
> generated a ColumnLabelProvider / EditingSupport for every attribute
> displayed/edited or for general purpose an ColumnLabelProvider /
> EditingSupport for every object type in your attribute:
That's what I was imagining. :-P
>
> --------8<--------
> StringLabelProvider extends ColumnLabelProvider
> StringEditingSupport extends EditingSupport
>
> DateLabelProvider extends ColumnLabelProvider
> DateEditingSupport extends EditingSupport
> --------8<--------
>
> I didn't had time in 3.4 to address generic sorting but if we also
> attach this to the ViewerColumn EMF could generate even
> StandardSorters :-)
>
> Now connect all this with Databinding which is also doable with the
> 3.3 API and you even get validation, ... .
It's sure hard to keep up with you guys!
>
> Tom
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: AdapterFactoryTableTreeEditor status [message #417153 is a reply to message #417087] |
Thu, 28 February 2008 07:41 |
Jim Steel
Messages: 54
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
--------------030800080808020208030209
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
G'day Tom, Ed,
I've been working through an example. Attached is a metamodel
hierarchy.ecore and a modified HierarchyEditor.java, based on my
understanding of what Tom was talking about. I also made changes to have
the ItemProviders implement ITableItemLabelProvider and delegate
getColumnImage() and getColumnText() off to the property descriptors.
(I'm happy to send these, or an archived version of the whole shebang,
if that is useful).
Perhaps this can serve to help any discussion about whether any
infrastructure classes (like AdapterFactoryTableTreeEditor was) need
updating in light of the JFace 3.3 stuff.
Feedback is also welcome, as this is essentially the approach I'm using
for my "real" editor.
Cheers,
Jim.
Ed Merks wrote:
> Tom,
>
> Comments below.
>
> Tom Schindl wrote:
>> Ed Merks schrieb:
>>> Tom,
>>>
>>> Comments below.
>>>
>>> Tom Schindl wrote:
>>>> Jim Steel schrieb:
>>>>> Ed Merks wrote:
>>>>>> Jim,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>> Jim Steel wrote:
>>>>>>> Hi Ed,
>>>>>>>
>>>>>>> Thanks for the reply - I was afraid you might say that. You're
>>>>>>> quite right, that AdapterFactoryTreeEditor seems to be the way to
>>>>>>> go, but AdapterFactoryTableTreeEditor had a whole of stuff built
>>>>>>> in to handle cells in other columns, that isn't there in the more
>>>>>>> basic AdapterFactoryTreeEditor.
>>>>>> To be honest, I haven't given it any thought at all. I suspect
>>>>>> your right that AdapterFactoryTreeEditor needs some attention to
>>>>>> support columns directly. If you open a bugzilla feature request
>>>>>> for this and help with at least producing some test cases I can
>>>>>> work with you to try to get the necessary support in place for it.
>>>>>
>>>>> I'm happy to do that.
>>>>>
>>>>>>>
>>>>>>> For example, I'm struggling at the moment with how to populate
>>>>>>> the cells in other columns with TreeItems. Presumably I need to
>>>>>>> modify the ItemProvider to create them somehow, but I'm really
>>>>>>> lost as to where I do that. Inheriting from
>>>>>>> ITableItemLabelProvider makes it really easy for text and image,
>>>>>>> but there doesn't seem to be an equivalent table content provider.
>>>>>> I'm not sure what you mean by this. The content provider just
>>>>>> determines the rows in the table while the label providers
>>>>>> determine what's displayed in the columns...
>>>>>
>>>>> Yes, the label providers determine what is displayed in the columns
>>>>> - I
>>>>> have implemented TableLabelItemProvider, and can see all the things I
>>>>> want to see in the other columns. However, I want to be able to
>>>>> edit the
>>>>> values. I can do this by associating basic vanilla celleditors with
>>>>> the columns, but I'd really like to have the celleditors that are
>>>>> appropriate to the property I'm editing - the celleditors generated
>>>>> by the PropertyDescriptor. I've been trying to do this using black
>>>>> magic involving TreeViewer.setCellEditors() and setCellModifiers(),
>>>>> but unfortunately, I can't seem get the right CellEditors at
>>>>> creation of the editor (since they depend on having an instantiated
>>>>> ItemProvider).
>>>>>
>>>>> I kind of figured that the alternative to doing this was to
>>>>> populate the columns with TreeItems, in the hope that the editors
>>>>> would automagically be the right ones (likely through calls to
>>>>> TreeEditor.setEditor(control, item, int)). I figured the path to
>>>>> creating the items would be via a ContentProvider. The current
>>>>> ITreeItemContentProvider creates TreeItems for the first
>>>>> column (the tree), but I need to make it make it create them in the
>>>>> other columns.
>>>>>
>>>>> I'm new to the whole framework, so I'll bow to advice on this, but it
>>>>> seems to me like there might need to be an extension of
>>>>> ITreeContentProvider (or some interface in that hierarchy) which
>>>>> provides additional methods "hasColumnChildren()" and
>>>>> "getColumnChildren()" (alternatively, follow the analogue of
>>>>> TableLabelProvider and have "getColumnItem(int columnIndex)").
>>>>> Then, the
>>>>> class that calls this (best I can tell, currently TreeViewer, so
>>>>> probably an extension of TreeViewer) needs to pick this up when it
>>>>> does
>>>>> redraw, etc.
>>>>>
>>>>> So I've been thinking about two directions of attack:
>>>>> - no content provider magic, just fiddling with celleditors and
>>>>> cellmodifiers during creation of the viewer
>>>>> - content provider changes in order to populate the tree with
>>>>> TreeItems so that I can then link TreeItems to appropriate editors.
>>>>>
>>>>
>>>> The new JFace-3.3 API comes to rescue for you :-) Take a look at the
>>>> whole new class infrastructure we provide.
>>>>
>>>> - TreeViewerColumn
>>>> - ColumnLabelProvider
>>> I imagine that one way to use this column label provider with EMF's
>>> item providers is that it would know the column index and could
>>> delegate to EMF's item providers support for
>>> ITableItemLabelProvider. Does that make sense?
>>
>> Well JFace internally is completely built upon ColumnLabelProvider (=
>> we are doing it the other way round mapping ITableLabelProvider
>> internally to ColumnLabelProviders we attach to
>> Table/TreeViewerColumn-s). See below for my ideas how EMF generated
>> Viewers could work in future :-)
> This would seem to imply having a separate set of item providers for
> each column, rather than a single one for dealing with the whole table.
> Maybe that's okay...
>>
>> The same happens to CellModifier and friends to support editing they
>> are mapped to EditingSupport-Instances.
> So the column just knows what aspect of the object it's editing. That
> makes sense.
>>
>>>> - EditingSupport
>>>>
>>>> If you look very close to EditingSupport you'll notice the method
>>>> getCellEditor(Object). This API has the big advantage that you can
>>>> decide which Editor to show base on the object-type in front of you.
>>> EMF's support generally relies on knowing the object of the row, but
>>> I think this will be the object of the cell. Is that right?
>>
>> No it's the object of the row. We completely abondon the notion of
>> indices because a EditingSupport/ColumnLabelProvider is directly
>> attached to the TableViewerColumn.
>>
>> The reason is simply reusage of LabelProviders and
>> EditingSupport-Objects. In former days reusage of CellModifier and
>> I*LabelProviders wasn't possible. Say in one part of your application
>> your had:
>>
>> -------------------------------------
>> | NAME | BIRTH | STREET |
>> -------------------------------------
>>
>> in the other one
>> ---------------------------
>> | BIRTH | NAME |
>> ---------------------------
>>
>> and in the last you have
>> ------------------------
>> | NAME | STREET |
>> ------------------------
>>
>>
>> With the new API you have to following objects you reuse all over:
>>
>> --------8<--------
>> PersonNameLabelProvider extends ColumnLabelProvider
>> PersonNameEditingSupport extends EditingSupport
>>
>> PersonBirthLabelProvider extends ColumnLabelProvider
>> PersonBirthEditingSupport extends EditingSupport
>>
>> PersonStreetLabelProvider extends ColumnLabelProvider
>> PersonStreetEditingSupport extends EditingSupport
>> --------8<--------
>>
>> Reusable all over ;-)
> I can still imagine having an item provider that knows about all the
> various columns it could support where the column index is just a "key"
> rather than really indicating a column number and then having a label
> provider that delegates the column labels to the appropriate key. (One
> of the nice things about Eclipse is it's ever progressing and improving,
> but that also means there are getting to be an awful lot of different
> ways to do the same thing.)
>>
>> Infact you could say when going the brute-force way that you could
>> generated a ColumnLabelProvider / EditingSupport for every attribute
>> displayed/edited or for general purpose an ColumnLabelProvider /
>> EditingSupport for every object type in your attribute:
> That's what I was imagining. :-P
>>
>> --------8<--------
>> StringLabelProvider extends ColumnLabelProvider
>> StringEditingSupport extends EditingSupport
>>
>> DateLabelProvider extends ColumnLabelProvider
>> DateEditingSupport extends EditingSupport
>> --------8<--------
>>
>> I didn't had time in 3.4 to address generic sorting but if we also
>> attach this to the ViewerColumn EMF could generate even
>> StandardSorters :-)
>>
>> Now connect all this with Databinding which is also doable with the
>> 3.3 API and you even get validation, ... .
> It's sure hard to keep up with you guys!
>>
>> Tom
>>
--------------030800080808020208030209
Content-Type: text/xml;
name="hierarchy.ecore"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="hierarchy.ecore"
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="hierarchy"
nsURI="http://hierarchy" nsPrefix="hierarchy">
<eClassifiers xsi:type="ecore:EClass" name="AbstractNode" abstract="true"/>
<eClassifiers xsi:type="ecore:EClass" name="LeafNode" eSuperTypes="#//AbstractNode">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="value" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="colour" eType="#//Colour"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="relatedNodes" upperBound="-1"
eType="#//LeafNode"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="isTentative" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EBoolean"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="ParentNode" eSuperTypes="#//AbstractNode">
<eStructuralFeatures xsi:type="ecore:EReference" name="contents" upperBound="-1"
eType="#//AbstractNode" containment="true"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EEnum" name="Colour">
<eLiterals name="red"/>
<eLiterals name="green" value="1"/>
<eLiterals name="blue" value="2"/>
</eClassifiers>
</ecore:EPackage>
--------------030800080808020208030209
Content-Type: text/plain;
name="HierarchyEditor.java"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="HierarchyEditor.java"
/**
* <copyright>
* </copyright>
*
* $Id$
*/
package hierarchy.presentation;
import java.io.IOException;
import java.io.InputStream;
import java.util.ArrayList;
import java.util.Collection;
import java.util.Collections;
import java.util.EventObject;
import java.util.HashMap;
import java.util.Iterator;
import java.util.LinkedHashMap;
import java.util.List;
import java.util.Map;
import org.eclipse.core.resources.IFile;
import org.eclipse.core.resources.IMarker;
import org.eclipse.core.resources.IResource;
import org.eclipse.core.resources.IResourceChangeEvent;
import org.eclipse.core.resources.IResourceChangeListener;
import org.eclipse.core.resources.IResourceDelta;
import org.eclipse.core.resources.IResourceDeltaVisitor;
import org.eclipse.core.resources.ResourcesPlugin;
import org.eclipse.core.runtime.CoreException;
import org.eclipse.core.runtime.IPath;
import org.eclipse.core.runtime.IProgressMonitor;
import org.eclipse.core.runtime.NullProgressMonitor;
import org.eclipse.jface.action.IMenuListener;
import org.eclipse.jface.action.IMenuManager;
import org.eclipse.jface.action.IStatusLineManager;
import org.eclipse.jface.action.IToolBarManager;
import org.eclipse.jface.action.MenuManager;
import org.eclipse.jface.action.Separator;
import org.eclipse.jface.dialogs.MessageDialog;
import org.eclipse.jface.dialogs.ProgressMonitorDialog;
import org.eclipse.jface.viewers.CellEditor;
import org.eclipse.jface.viewers.ColumnWeightData;
import org.eclipse.jface.viewers.EditingSupport;
import org.eclipse.jface.viewers.ISelection;
import org.eclipse.jface.viewers.ISelectionChangedListener;
import org.eclipse.jface.viewers.ISelectionProvider;
import org.eclipse.jface.viewers.IStructuredSelection;
import org.eclipse.jface.viewers.ListViewer;
import org.eclipse.jface.viewers.SelectionChangedEvent;
import org.eclipse.jface.viewers.StructuredSelection;
import org.eclipse.jface.viewers.StructuredViewer;
import org.eclipse.jface.viewers.TableLayout;
import org.eclipse.jface.viewers.TableViewer;
import org.eclipse.jface.viewers.TreeViewer;
import org.eclipse.jface.viewers.TreeViewerColumn;
import org.eclipse.jface.viewers.Viewer;
import org.eclipse.swt.SWT;
import org.eclipse.swt.custom.CTabFolder;
import org.eclipse.swt.dnd.DND;
import org.eclipse.swt.dnd.Transfer;
import org.eclipse.swt.events.ControlAdapter;
import org.eclipse.swt.events.ControlEvent;
import org.eclipse.swt.graphics.Point;
import org.eclipse.swt.layout.FillLayout;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.swt.widgets.Menu;
import org.eclipse.swt.widgets.Table;
import org.eclipse.swt.widgets.TableColumn;
import org.eclipse.swt.widgets.Tree;
import org.eclipse.swt.widgets.TreeColumn;
import org.eclipse.ui.IActionBars;
import org.eclipse.ui.IEditorInput;
import org.eclipse.ui.IEditorPart;
import org.eclipse.ui.IEditorSite;
import org.eclipse.ui.IPartListener;
import org.eclipse.ui.IWorkbenchPart;
import org.eclipse.ui.PartInitException;
import org.eclipse.ui.dialogs.SaveAsDialog;
import org.eclipse.ui.ide.IGotoMarker;
import org.eclipse.ui.part.FileEditorInput;
import org.eclipse.ui.part.MultiPageEditorPart;
import org.eclipse.ui.views.contentoutline.ContentOutline;
import org.eclipse.ui.views.contentoutline.ContentOutlinePage;
import org.eclipse.ui.views.contentoutline.IContentOutlinePage;
import org.eclipse.ui.views.properties.IPropertySheetPage;
import org.eclipse.ui.views.properties.PropertySheet;
import org.eclipse.ui.views.properties.PropertySheetPage;
import org.eclipse.emf.common.command.BasicCommandStack;
import org.eclipse.emf.common.command.Command;
import org.eclipse.emf.common.command.CommandStack;
import org.eclipse.emf.common.command.CommandStackListener;
import org.eclipse.emf.common.notify.AdapterFactory;
import org.eclipse.emf.common.notify.Notification;
import org.eclipse.emf.common.ui.MarkerHelper;
import org.eclipse.emf.common.ui.ViewerPane;
import org.eclipse.emf.common.ui.editor.ProblemEditorPart;
import org.eclipse.emf.common.ui.viewer.IViewerProvider;
import org.eclipse.emf.common.util.BasicDiagnostic;
import org.eclipse.emf.common.util.Diagnostic;
import org.eclipse.emf.common.util.URI;
import org.eclipse.emf.ecore.EObject;
import org.eclipse.emf.ecore.EValidator;
import org.eclipse.emf.ecore.resource.Resource;
import org.eclipse.emf.ecore.resource.ResourceSet;
import org.eclipse.emf.ecore.util.EContentAdapter;
import org.eclipse.emf.ecore.util.EcoreUtil;
import org.eclipse.emf.edit.command.SetCommand;
import org.eclipse.emf.edit.domain.AdapterFactoryEditingDomain;
import org.eclipse.emf.edit.domain.EditingDomain;
import org.eclipse.emf.edit.domain.IEditingDomainProvider;
import org.eclipse.emf.edit.provider.AdapterFactoryItemDelegator;
import org.eclipse.emf.edit.provider.ComposedAdapterFactory;
import org.eclipse.emf.edit.provider.IItemLabelProvider;
import org.eclipse.emf.edit.provider.IItemPropertyDescriptor;
import org.eclipse.emf.edit.provider.ItemPropertyDescriptor;
import org.eclipse.emf.edit.provider.ReflectiveItemProviderAdapterF actory;
import org.eclipse.emf.edit.provider.resource.ResourceItemProviderA dapterFactory;
import org.eclipse.emf.edit.ui.action.EditingDomainActionBarContrib utor;
import org.eclipse.emf.edit.ui.celleditor.AdapterFactoryTreeEditor;
import org.eclipse.emf.edit.ui.dnd.EditingDomainViewerDropAdapter;
import org.eclipse.emf.edit.ui.dnd.LocalTransfer;
import org.eclipse.emf.edit.ui.dnd.ViewerDragAdapter;
import org.eclipse.emf.edit.ui.provider.AdapterFactoryContentProvid er;
import org.eclipse.emf.edit.ui.provider.AdapterFactoryLabelProvider ;
import org.eclipse.emf.edit.ui.provider.PropertyDescriptor;
import org.eclipse.emf.edit.ui.provider.UnwrappingSelectionProvider ;
import org.eclipse.emf.edit.ui.util.EditUIMarkerHelper;
import org.eclipse.emf.edit.ui.util.EditUIUtil;
import org.eclipse.emf.edit.ui.view.ExtendedPropertySheetPage;
import hierarchy.HierarchyPackage;
import hierarchy.LeafNode;
import hierarchy.provider.HierarchyEditPlugin;
import hierarchy.provider.HierarchyItemProviderAdapterFactory;
import hierarchy.provider.LeafNodeItemProvider;
import org.eclipse.ui.actions.WorkspaceModifyOperation;
/**
* This is an example of a Hierarchy model editor.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public class HierarchyEditor
extends MultiPageEditorPart
implements IEditingDomainProvider, ISelectionProvider, IMenuListener, IViewerProvider, IGotoMarker {
/**
* This keeps track of the editing domain that is used to track all changes to the model.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected AdapterFactoryEditingDomain editingDomain;
/**
* This is the one adapter factory used for providing views of the model.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected ComposedAdapterFactory adapterFactory;
/**
* This is the content outline page.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected IContentOutlinePage contentOutlinePage;
/**
* This is a kludge...
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected IStatusLineManager contentOutlineStatusLineManager;
/**
* This is the content outline page's viewer.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected TreeViewer contentOutlineViewer;
/**
* This is the property sheet page.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected PropertySheetPage propertySheetPage;
/**
* This is the viewer that shadows the selection in the content outline.
* The parent relation must be correctly defined for this to work.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected TreeViewer selectionViewer;
/**
* This inverts the roll of parent and child in the content provider and show parents as a tree.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected TreeViewer parentViewer;
/**
* This shows how a tree view works.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected TreeViewer treeViewer;
/**
* This shows how a list view works.
* A list viewer doesn't support icons.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected ListViewer listViewer;
/**
* This shows how a table view works.
* A table can be used as a list with icons.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected TableViewer tableViewer;
/**
* This shows how a tree view with columns works.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected TreeViewer treeViewerWithColumns;
/**
* This keeps track of the active viewer pane, in the book.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected ViewerPane currentViewerPane;
/**
* This keeps track of the active content viewer, which may be either one of the viewers in the pages or the content outline viewer.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected Viewer currentViewer;
/**
* This listens to which ever viewer is active.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected ISelectionChangedListener selectionChangedListener;
/**
* This keeps track of all the {@link org.eclipse.jface.viewers.ISelectionChangedListener}s that are listening to this editor.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected Collection<ISelectionChangedListener> selectionChangedListeners = new ArrayList<ISelectionChangedListener>();
/**
* This keeps track of the selection of the editor as a whole.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected ISelection editorSelection = StructuredSelection.EMPTY;
/**
* The MarkerHelper is responsible for creating workspace resource markers presented
* in Eclipse's Problems View.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected MarkerHelper markerHelper = new EditUIMarkerHelper();
/**
* This listens for when the outline becomes active
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected IPartListener partListener =
new IPartListener() {
public void partActivated(IWorkbenchPart p) {
if (p instanceof ContentOutline) {
if (((ContentOutline)p).getCurrentPage() == contentOutlinePage) {
getActionBarContributor().setActiveEditor(HierarchyEditor.th is);
setCurrentViewer(contentOutlineViewer);
}
}
else if (p instanceof PropertySheet) {
if (((PropertySheet)p).getCurrentPage() == propertySheetPage) {
getActionBarContributor().setActiveEditor(HierarchyEditor.th is);
handleActivate();
}
}
else if (p == HierarchyEditor.this) {
handleActivate();
}
}
public void partBroughtToTop(IWorkbenchPart p) {
// Ignore.
}
public void partClosed(IWorkbenchPart p) {
// Ignore.
}
public void partDeactivated(IWorkbenchPart p) {
// Ignore.
}
public void partOpened(IWorkbenchPart p) {
// Ignore.
}
};
/**
* Resources that have been removed since last activation.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected Collection<Resource> removedResources = new ArrayList<Resource>();
/**
* Resources that have been changed since last activation.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected Collection<Resource> changedResources = new ArrayList<Resource>();
/**
* Resources that have been saved.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected Collection<Resource> savedResources = new ArrayList<Resource>();
/**
* Map to store the diagnostic associated with a resource.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected Map<Resource, Diagnostic> resourceToDiagnosticMap = new LinkedHashMap<Resource, Diagnostic>();
/**
* Controls whether the problem indication should be updated.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected boolean updateProblemIndication = true;
/**
* Adapter used to update the problem indication when resources are demanded loaded.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected EContentAdapter problemIndicationAdapter =
new EContentAdapter() {
@Override
public void notifyChanged(Notification notification) {
if (notification.getNotifier() instanceof Resource) {
switch (notification.getFeatureID(Resource.class)) {
case Resource.RESOURCE__IS_LOADED:
case Resource.RESOURCE__ERRORS:
case Resource.RESOURCE__WARNINGS: {
Resource resource = (Resource)notification.getNotifier();
Diagnostic diagnostic = analyzeResourceProblems(resource, null);
if (diagnostic.getSeverity() != Diagnostic.OK) {
resourceToDiagnosticMap.put(resource, diagnostic);
}
else {
resourceToDiagnosticMap.remove(resource);
}
if (updateProblemIndication) {
getSite().getShell().getDisplay().asyncExec
(new Runnable() {
public void run() {
updateProblemIndication();
}
});
}
break;
}
}
}
else {
super.notifyChanged(notification);
}
}
@Override
protected void setTarget(Resource target) {
basicSetTarget(target);
}
@Override
protected void unsetTarget(Resource target) {
basicUnsetTarget(target);
}
};
/**
* This listens for workspace changes.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected IResourceChangeListener resourceChangeListener =
new IResourceChangeListener() {
public void resourceChanged(IResourceChangeEvent event) {
// Only listening to these.
// if (event.getType() == IResourceDelta.POST_CHANGE)
{
IResourceDelta delta = event.getDelta();
try {
class ResourceDeltaVisitor implements IResourceDeltaVisitor {
protected ResourceSet resourceSet = editingDomain.getResourceSet();
protected Collection<Resource> changedResources = new ArrayList<Resource>();
protected Collection<Resource> removedResources = new ArrayList<Resource>();
public boolean visit(IResourceDelta delta) {
if (delta.getFlags() != IResourceDelta.MARKERS &&
delta.getResource().getType() == IResource.FILE) {
if ((delta.getKind() & (IResourceDelta.CHANGED | IResourceDelta.REMOVED)) != 0) {
Resource resource = resourceSet.getResource(URI.createURI(delta.getFullPath().to String()), false);
if (resource != null) {
if ((delta.getKind() & IResourceDelta.REMOVED) != 0) {
removedResources.add(resource);
}
else if (!savedResources.remove(resource)) {
changedResources.add(resource);
}
}
}
}
return true;
}
public Collection<Resource> getChangedResources() {
return changedResources;
}
public Collection<Resource> getRemovedResources() {
return removedResources;
}
}
ResourceDeltaVisitor visitor = new ResourceDeltaVisitor();
delta.accept(visitor);
if (!visitor.getRemovedResources().isEmpty()) {
removedResources.addAll(visitor.getRemovedResources());
if (!isDirty()) {
getSite().getShell().getDisplay().asyncExec
(new Runnable() {
public void run() {
getSite().getPage().closeEditor(HierarchyEditor.this, false);
HierarchyEditor.this.dispose();
}
});
}
}
if (!visitor.getChangedResources().isEmpty()) {
changedResources.addAll(visitor.getChangedResources());
if (getSite().getPage().getActiveEditor() == HierarchyEditor.this) {
getSite().getShell().getDisplay().asyncExec
(new Runnable() {
public void run() {
handleActivate();
}
});
}
}
}
catch (CoreException exception) {
HierarchyEditorPlugin.INSTANCE.log(exception);
}
}
}
};
/**
* Handles activation of the editor or it's associated views.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected void handleActivate() {
// Recompute the read only state.
//
if (editingDomain.getResourceToReadOnlyMap() != null) {
editingDomain.getResourceToReadOnlyMap().clear();
// Refresh any actions that may become enabled or disabled.
//
setSelection(getSelection());
}
if (!removedResources.isEmpty()) {
if (handleDirtyConflict()) {
getSite().getPage().closeEditor(HierarchyEditor.this, false);
HierarchyEditor.this.dispose();
}
else {
removedResources.clear();
changedResources.clear();
savedResources.clear();
}
}
else if (!changedResources.isEmpty()) {
changedResources.removeAll(savedResources);
handleChangedResources();
changedResources.clear();
savedResources.clear();
}
}
/**
* Handles what to do with changed resources on activation.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected void handleChangedResources() {
if (!changedResources.isEmpty() && (!isDirty() || handleDirtyConflict())) {
editingDomain.getCommandStack().flush();
updateProblemIndication = false;
for (Resource resource : changedResources) {
if (resource.isLoaded()) {
resource.unload();
try {
resource.load(Collections.EMPTY_MAP);
}
catch (IOException exception) {
if (!resourceToDiagnosticMap.containsKey(resource)) {
resourceToDiagnosticMap.put(resource, analyzeResourceProblems(resource, exception));
}
}
}
}
updateProblemIndication = true;
updateProblemIndication();
}
}
/**
* Updates the problems indication with the information described in the specified diagnostic.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected void updateProblemIndication() {
if (updateProblemIndication) {
BasicDiagnostic diagnostic =
new BasicDiagnostic
(Diagnostic.OK,
"hierarchy.editor",
0,
null,
new Object [] { editingDomain.getResourceSet() });
for (Diagnostic childDiagnostic : resourceToDiagnosticMap.values()) {
if (childDiagnostic.getSeverity() != Diagnostic.OK) {
diagnostic.add(childDiagnostic);
}
}
int lastEditorPage = getPageCount() - 1;
if (lastEditorPage >= 0 && getEditor(lastEditorPage) instanceof ProblemEditorPart) {
((ProblemEditorPart)getEditor(lastEditorPage)).setDiagnostic (diagnostic);
if (diagnostic.getSeverity() != Diagnostic.OK) {
setActivePage(lastEditorPage);
}
}
else if (diagnostic.getSeverity() != Diagnostic.OK) {
ProblemEditorPart problemEditorPart = new ProblemEditorPart();
problemEditorPart.setDiagnostic(diagnostic);
problemEditorPart.setMarkerHelper(markerHelper);
try {
addPage(++lastEditorPage, problemEditorPart, getEditorInput());
setPageText(lastEditorPage, problemEditorPart.getPartName());
setActivePage(lastEditorPage);
showTabs();
}
catch (PartInitException exception) {
HierarchyEditorPlugin.INSTANCE.log(exception);
}
}
if (markerHelper.hasMarkers(editingDomain.getResourceSet())) {
markerHelper.deleteMarkers(editingDomain.getResourceSet());
if (diagnostic.getSeverity() != Diagnostic.OK) {
try {
markerHelper.createMarkers(diagnostic);
}
catch (CoreException exception) {
HierarchyEditorPlugin.INSTANCE.log(exception);
}
}
}
}
}
/**
* Shows a dialog that asks if conflicting changes should be discarded.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected boolean handleDirtyConflict() {
return
MessageDialog.openQuestion
(getSite().getShell(),
getString("_UI_FileConflict_label"),
getString("_WARN_FileConflict"));
}
/**
* This creates a model editor.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public HierarchyEditor() {
super();
initializeEditingDomain();
}
/**
* This sets up the editing domain for the model editor.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected void initializeEditingDomain() {
// Create an adapter factory that yields item providers.
//
adapterFactory = new ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
adapterFactory.addAdapterFactory(new ResourceItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new HierarchyItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new ReflectiveItemProviderAdapterFactory());
// Create the command stack that will notify this editor as commands are executed.
//
BasicCommandStack commandStack = new BasicCommandStack();
// Add a listener to set the most recent command's affected objects to be the selection of the viewer with focus.
//
commandStack.addCommandStackListener
(new CommandStackListener() {
public void commandStackChanged(final EventObject event) {
getContainer().getDisplay().asyncExec
(new Runnable() {
public void run() {
firePropertyChange(IEditorPart.PROP_DIRTY);
// Try to select the affected objects.
//
Command mostRecentCommand = ((CommandStack)event.getSource()).getMostRecentCommand();
if (mostRecentCommand != null) {
setSelectionToViewer(mostRecentCommand.getAffectedObjects()) ;
}
if (propertySheetPage != null && !propertySheetPage.getControl().isDisposed()) {
propertySheetPage.refresh();
}
}
});
}
});
// Create the editing domain with a special command stack.
//
editingDomain = new AdapterFactoryEditingDomain(adapterFactory, commandStack, new HashMap<Resource, Boolean>());
}
/**
* This is here for the listener to be able to call it.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
@Override
protected void firePropertyChange(int action) {
super.firePropertyChange(action);
}
/**
* This sets the selection into whichever viewer is active.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public void setSelectionToViewer(Collection<?> collection) {
final Collection<?> theSelection = collection;
// Make sure it's okay.
//
if (theSelection != null && !theSelection.isEmpty()) {
// I don't know if this should be run this deferred
// because we might have to give the editor a chance to process the viewer update events
// and hence to update the views first.
//
//
Runnable runnable =
new Runnable() {
public void run() {
// Try to select the items in the current content viewer of the editor.
//
if (currentViewer != null) {
currentViewer.setSelection(new StructuredSelection(theSelection.toArray()), true);
}
}
};
runnable.run();
}
}
/**
* This returns the editing domain as required by the {@link IEditingDomainProvider} interface.
* This is important for implementing the static methods of {@link AdapterFactoryEditingDomain}
* and for supporting {@link org.eclipse.emf.edit.ui.action.CommandAction}.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public EditingDomain getEditingDomain() {
return editingDomain;
}
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public class ReverseAdapterFactoryContentProvider extends AdapterFactoryContentProvider {
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public ReverseAdapterFactoryContentProvider(AdapterFactory adapterFactory) {
super(adapterFactory);
}
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
@Override
public Object [] getElements(Object object) {
Object parent = super.getParent(object);
return (parent == null ? Collections.EMPTY_SET : Collections.singleton(parent)).toArray();
}
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
@Override
public Object [] getChildren(Object object) {
Object parent = super.getParent(object);
return (parent == null ? Collections.EMPTY_SET : Collections.singleton(parent)).toArray();
}
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
@Override
public boolean hasChildren(Object object) {
Object parent = super.getParent(object);
return parent != null;
}
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
@Override
public Object getParent(Object object) {
return null;
}
}
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public void setCurrentViewerPane(ViewerPane viewerPane) {
if (currentViewerPane != viewerPane) {
if (currentViewerPane != null) {
currentViewerPane.showFocus(false);
}
currentViewerPane = viewerPane;
}
setCurrentViewer(currentViewerPane.getViewer());
}
/**
* This makes sure that one content viewer, either for the current page or the outline view, if it has focus,
* is the current one.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public void setCurrentViewer(Viewer viewer) {
// If it is changing...
//
if (currentViewer != viewer) {
if (selectionChangedListener == null) {
// Create the listener on demand.
//
selectionChangedListener =
new ISelectionChangedListener() {
// This just notifies those things that are affected by the section.
//
public void selectionChanged(SelectionChangedEvent selectionChangedEvent) {
setSelection(selectionChangedEvent.getSelection());
}
};
}
// Stop listening to the old one.
//
if (currentViewer != null) {
currentViewer.removeSelectionChangedListener(selectionChange dListener);
}
// Start listening to the new one.
//
if (viewer != null) {
viewer.addSelectionChangedListener(selectionChangedListener) ;
}
// Remember it.
//
currentViewer = viewer;
// Set the editors selection based on the current viewer's selection.
//
setSelection(currentViewer == null ? StructuredSelection.EMPTY : currentViewer.getSelection());
}
}
/**
* This returns the viewer as required by the {@link IViewerProvider} interface.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public Viewer getViewer() {
return currentViewer;
}
/**
* This creates a context menu for the viewer and adds a listener as well registering the menu for extension.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected void createContextMenuFor(StructuredViewer viewer) {
MenuManager contextMenu = new MenuManager("#PopUp");
contextMenu.add(new Separator("additions"));
contextMenu.setRemoveAllWhenShown(true);
contextMenu.addMenuListener(this);
Menu menu= contextMenu.createContextMenu(viewer.getControl());
viewer.getControl().setMenu(menu);
getSite().registerContextMenu(contextMenu, new UnwrappingSelectionProvider(viewer));
int dndOperations = DND.DROP_COPY | DND.DROP_MOVE | DND.DROP_LINK;
Transfer[] transfers = new Transfer[] { LocalTransfer.getInstance() };
viewer.addDragSupport(dndOperations, transfers, new ViewerDragAdapter(viewer));
viewer.addDropSupport(dndOperations, transfers, new EditingDomainViewerDropAdapter(editingDomain, viewer));
}
/**
* This is the method called to load a resource into the editing domain's resource set based on the editor's input.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public void createModel() {
URI resourceURI = EditUIUtil.getURI(getEditorInput());
Exception exception = null;
Resource resource = null;
try {
// Load the resource through the editing domain.
//
resource = editingDomain.getResourceSet().getResource(resourceURI, true);
}
catch (Exception e) {
exception = e;
resource = editingDomain.getResourceSet().getResource(resourceURI, false);
}
Diagnostic diagnostic = analyzeResourceProblems(resource, exception);
if (diagnostic.getSeverity() != Diagnostic.OK) {
resourceToDiagnosticMap.put(resource, analyzeResourceProblems(resource, exception));
}
editingDomain.getResourceSet().eAdapters().add(problemIndica tionAdapter);
}
/**
* Returns a diagnostic describing the errors and warnings listed in the resource
* and the specified exception (if any).
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public Diagnostic analyzeResourceProblems(Resource resource, Exception exception) {
if (!resource.getErrors().isEmpty() || !resource.getWarnings().isEmpty()) {
BasicDiagnostic basicDiagnostic =
new BasicDiagnostic
(Diagnostic.ERROR,
"hierarchy.editor",
0,
getString("_UI_CreateModelError_message", resource.getURI()),
new Object [] { exception == null ? (Object)resource : exception });
basicDiagnostic.merge(EcoreUtil.computeDiagnostic(resource, true));
return basicDiagnostic;
}
else if (exception != null) {
return
new BasicDiagnostic
(Diagnostic.ERROR,
"hierarchy.editor",
0,
getString("_UI_CreateModelError_message", resource.getURI()),
new Object[] { exception });
}
else {
return Diagnostic.OK_INSTANCE;
}
}
/**
* This is the method used by the framework to install your own controls.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated NOT
*/
@Override
public void createPages() {
// Creates the model from the editor input
//
createModel();
// Only creates the other pages if there is something that can be edited
//
if (!getEditingDomain().getResourceSet().getResources().isEmpty () &&
!(getEditingDomain().getResourceSet().getResources().get(0)) .getContents().isEmpty()) {
// Create a page for the selection tree view.
//
{
ViewerPane viewerPane =
new ViewerPane(getSite().getPage(), HierarchyEditor.this) {
@Override
public Viewer createViewer(Composite composite) {
Tree tree = new Tree(composite, SWT.MULTI);
TreeViewer newTreeViewer = new TreeViewer(tree);
return newTreeViewer;
}
@Override
public void requestActivation() {
super.requestActivation();
setCurrentViewerPane(this);
}
};
viewerPane.createControl(getContainer());
selectionViewer = (TreeViewer)viewerPane.getViewer();
selectionViewer.setContentProvider(new AdapterFactoryContentProvider(adapterFactory));
selectionViewer.setLabelProvider(new AdapterFactoryLabelProvider(adapterFactory));
selectionViewer.setInput(editingDomain.getResourceSet());
selectionViewer.setSelection(new StructuredSelection(editingDomain.getResourceSet().getResour ces().get(0)), true);
viewerPane.setTitle(editingDomain.getResourceSet());
new AdapterFactoryTreeEditor(selectionViewer.getTree(), adapterFactory);
createContextMenuFor(selectionViewer);
int pageIndex = addPage(viewerPane.getControl());
setPageText(pageIndex, getString("_UI_SelectionPage_label"));
}
// Create a page for the parent tree view.
//
{
ViewerPane viewerPane =
new ViewerPane(getSite().getPage(), HierarchyEditor.this) {
@Override
public Viewer createViewer(Composite composite) {
Tree tree = new Tree(composite, SWT.MULTI);
TreeViewer newTreeViewer = new TreeViewer(tree);
return newTreeViewer;
}
@Override
public void requestActivation() {
super.requestActivation();
setCurrentViewerPane(this);
}
};
viewerPane.createControl(getContainer());
parentViewer = (TreeViewer)viewerPane.getViewer();
parentViewer.setAutoExpandLevel(30);
parentViewer.setContentProvider(new ReverseAdapterFactoryContentProvider(adapterFactory));
parentViewer.setLabelProvider(new AdapterFactoryLabelProvider(adapterFactory));
createContextMenuFor(parentViewer);
int pageIndex = addPage(viewerPane.getControl());
setPageText(pageIndex, getString("_UI_ParentPage_label"));
}
// This is the page for the list viewer
//
{
ViewerPane viewerPane =
new ViewerPane(getSite().getPage(), HierarchyEditor.this) {
@Override
public Viewer createViewer(Composite composite) {
return new ListViewer(composite);
}
@Override
public void requestActivation() {
super.requestActivation();
setCurrentViewerPane(this);
}
};
viewerPane.createControl(getContainer());
listViewer = (ListViewer)viewerPane.getViewer();
listViewer.setContentProvider(new AdapterFactoryContentProvider(adapterFactory));
listViewer.setLabelProvider(new AdapterFactoryLabelProvider(adapterFactory));
createContextMenuFor(listViewer);
int pageIndex = addPage(viewerPane.getControl());
setPageText(pageIndex, getString("_UI_ListPage_label"));
}
// This is the page for the tree viewer
//
{
ViewerPane viewerPane =
new ViewerPane(getSite().getPage(), HierarchyEditor.this) {
@Override
public Viewer createViewer(Composite composite) {
return new TreeViewer(composite);
}
@Override
public void requestActivation() {
super.requestActivation();
setCurrentViewerPane(this);
}
};
viewerPane.createControl(getContainer());
treeViewer = (TreeViewer)viewerPane.getViewer();
treeViewer.setContentProvider(new AdapterFactoryContentProvider(adapterFactory));
treeViewer.setLabelProvider(new AdapterFactoryLabelProvider(adapterFactory));
new AdapterFactoryTreeEditor(treeViewer.getTree(), adapterFactory);
createContextMenuFor(treeViewer);
int pageIndex = addPage(viewerPane.getControl());
setPageText(pageIndex, getString("_UI_TreePage_label"));
}
// This is the page for the table viewer.
//
{
ViewerPane viewerPane =
new ViewerPane(getSite().getPage(), HierarchyEditor.this) {
@Override
public Viewer createViewer(Composite composite) {
return new TableViewer(composite);
}
@Override
public void requestActivation() {
super.requestActivation();
setCurrentViewerPane(this);
}
};
viewerPane.createControl(getContainer());
tableViewer = (TableViewer)viewerPane.getViewer();
Table table = tableViewer.getTable();
TableLayout layout = new TableLayout();
table.setLayout(layout);
table.setHeaderVisible(true);
table.setLinesVisible(true);
TableColumn objectColumn = new TableColumn(table, SWT.NONE);
layout.addColumnData(new ColumnWeightData(3, 100, true));
objectColumn.setText(getString("_UI_ObjectColumn_label"));
objectColumn.setResizable(true);
TableColumn selfColumn = new TableColumn(table, SWT.NONE);
layout.addColumnData(new ColumnWeightData(2, 100, true));
selfColumn.setText(getString("_UI_SelfColumn_label"));
selfColumn.setResizable(true);
tableViewer.setColumnProperties(new String [] {"a", "b"});
tableViewer.setContentProvider(new AdapterFactoryContentProvider(adapterFactory));
tableViewer.setLabelProvider(new AdapterFactoryLabelProvider(adapterFactory));
createContextMenuFor(tableViewer);
int pageIndex = addPage(viewerPane.getControl());
setPageText(pageIndex, getString("_UI_TablePage_label"));
}
// This is the page for the table tree viewer.
//
{
ViewerPane viewerPane =
new ViewerPane(getSite().getPage(), HierarchyEditor.this) {
@Override
public Viewer createViewer(Composite composite) {
return new TreeViewer(composite);
}
@Override
public void requestActivation() {
super.requestActivation();
setCurrentViewerPane(this);
}
};
viewerPane.createControl(getContainer());
treeViewerWithColumns = (TreeViewer)viewerPane.getViewer();
Tree tree = treeViewerWithColumns.getTree();
tree.setLayoutData(new FillLayout());
tree.setHeaderVisible(true);
tree.setLinesVisible(true);
TreeColumn objectColumn = new TreeColumn(tree, SWT.NONE);
objectColumn.setText(getString("_UI_ObjectColumn_label"));
objectColumn.setResizable(true);
objectColumn.setWidth(250);
// TreeColumn selfColumn = new TreeColumn(tree, SWT.NONE);
// selfColumn.setText(getString("_UI_SelfColumn_label"));
// selfColumn.setResizable(true);
// selfColumn.setWidth(200);
TreeColumn valueColumn = new TreeColumn(tree, SWT.NONE);
valueColumn.setText("Value");
valueColumn.setResizable(true);
valueColumn.setWidth(250);
TreeViewerColumn valueTVC = new TreeViewerColumn(treeViewerWithColumns, valueColumn);
EditingSupport valueEdSupport = new EditingSupport(treeViewerWithColumns) {
@Override
protected boolean canEdit(Object element) {
if (element instanceof LeafNode) return true;
return false;
}
@Override
protected CellEditor getCellEditor(Object element) {
if (element instanceof LeafNode) {
LeafNode node = (LeafNode) element;
LeafNodeItemProvider itemProvider = (LeafNodeItemProvider) adapterFactory.adapt(node, IItemLabelProvider.class);
IItemPropertyDescriptor itemPropertyDescriptor = itemProvider.getPropertyDescriptor(node, HierarchyEditPlugin.INSTANCE.getString("_UI_LeafNode_value_feature "));
PropertyDescriptor propertyDescriptor = new PropertyDescriptor(node, itemPropertyDescriptor);
CellEditor cellEditor = propertyDescriptor.createPropertyEditor((Composite) this.getViewer().getControl());
return cellEditor;
}
return null;
}
@Override
protected Object getValue(Object element) {
if (element instanceof LeafNode) return ((LeafNode) element).getValue();
return null;
}
@Override
protected void setValue(Object element, Object value) {
if (element instanceof LeafNode) {
LeafNode node = (LeafNode) element;
Command cmd = SetCommand.create(editingDomain, node, HierarchyPackage.eINSTANCE.getLeafNode_Value(), value);
editingDomain.getCommandStack().execute(cmd);
}
}
};
valueTVC.setEditingSupport(valueEdSupport);
// Column for colour feature
TreeColumn colourColumn = new TreeColumn(tree, SWT.NONE);
colourColumn.setText("Colour");
colourColumn.setResizable(true);
colourColumn.setWidth(100);
TreeViewerColumn colourTVC = new TreeViewerColumn(treeViewerWithColumns, colourColumn);
EditingSupport colourEdSupport = new EditingSupport(treeViewerWithColumns) {
@Override
protected boolean canEdit(Object element) {
if (element instanceof LeafNode) return true;
return false;
}
@Override
protected CellEditor getCellEditor(Object element) {
if (element instanceof LeafNode) {
LeafNode node = (LeafNode) element;
LeafNodeItemProvider itemProvider = (LeafNodeItemProvider) adapterFactory.adapt(node, IItemLabelProvider.class);
IItemPropertyDescriptor itemPropertyDescriptor = itemProvider.getPropertyDescriptor(node, HierarchyEditPlugin.INSTANCE.getString("_UI_LeafNode_colour_feature "));
PropertyDescriptor propertyDescriptor = new PropertyDescriptor(node, itemPropertyDescriptor);
CellEditor cellEditor = propertyDescriptor.createPropertyEditor((Composite) this.getViewer().getControl());
return cellEditor;
}
return nu
|
|
|
| Re: AdapterFactoryTableTreeEditor status [message #417154 is a reply to message #417153] |
Thu, 28 February 2008 08:32 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Hi Jim,
It would be great if you could send me the packaged project or even
better let's create a bugzilla where we can discuss adoption of JFace
3.3 in EMF generated editors (this could be one of the topics we can
beside discuss on the "EclipseCon - BoF - UI Component Programming Best
Practices (SWT, Nebula, JFace, Databinding ...)").
Tom
Jim Steel schrieb:
>
> G'day Tom, Ed,
>
> I've been working through an example. Attached is a metamodel
> hierarchy.ecore and a modified HierarchyEditor.java, based on my
> understanding of what Tom was talking about. I also made changes to have
> the ItemProviders implement ITableItemLabelProvider and delegate
> getColumnImage() and getColumnText() off to the property descriptors.
> (I'm happy to send these, or an archived version of the whole shebang,
> if that is useful).
>
> Perhaps this can serve to help any discussion about whether any
> infrastructure classes (like AdapterFactoryTableTreeEditor was) need
> updating in light of the JFace 3.3 stuff.
>
> Feedback is also welcome, as this is essentially the approach I'm using
> for my "real" editor.
>
> Cheers,
>
> Jim.
>
>
>
>
> Ed Merks wrote:
>> Tom,
>>
>> Comments below.
>>
>> Tom Schindl wrote:
>>> Ed Merks schrieb:
>>>> Tom,
>>>>
>>>> Comments below.
>>>>
>>>> Tom Schindl wrote:
>>>>> Jim Steel schrieb:
>>>>>> Ed Merks wrote:
>>>>>>> Jim,
>>>>>>>
>>>>>>> Comments below.
>>>>>>>
>>>>>>> Jim Steel wrote:
>>>>>>>> Hi Ed,
>>>>>>>>
>>>>>>>> Thanks for the reply - I was afraid you might say that. You're
>>>>>>>> quite right, that AdapterFactoryTreeEditor seems to be the way
>>>>>>>> to go, but AdapterFactoryTableTreeEditor had a whole of stuff
>>>>>>>> built in to handle cells in other columns, that isn't there in
>>>>>>>> the more basic AdapterFactoryTreeEditor.
>>>>>>> To be honest, I haven't given it any thought at all. I suspect
>>>>>>> your right that AdapterFactoryTreeEditor needs some attention to
>>>>>>> support columns directly. If you open a bugzilla feature request
>>>>>>> for this and help with at least producing some test cases I can
>>>>>>> work with you to try to get the necessary support in place for it.
>>>>>>
>>>>>> I'm happy to do that.
>>>>>>
>>>>>>>>
>>>>>>>> For example, I'm struggling at the moment with how to populate
>>>>>>>> the cells in other columns with TreeItems. Presumably I need to
>>>>>>>> modify the ItemProvider to create them somehow, but I'm really
>>>>>>>> lost as to where I do that. Inheriting from
>>>>>>>> ITableItemLabelProvider makes it really easy for text and image,
>>>>>>>> but there doesn't seem to be an equivalent table content provider.
>>>>>>> I'm not sure what you mean by this. The content provider just
>>>>>>> determines the rows in the table while the label providers
>>>>>>> determine what's displayed in the columns...
>>>>>>
>>>>>> Yes, the label providers determine what is displayed in the
>>>>>> columns - I
>>>>>> have implemented TableLabelItemProvider, and can see all the things I
>>>>>> want to see in the other columns. However, I want to be able to
>>>>>> edit the
>>>>>> values. I can do this by associating basic vanilla celleditors
>>>>>> with the columns, but I'd really like to have the celleditors that
>>>>>> are appropriate to the property I'm editing - the celleditors
>>>>>> generated by the PropertyDescriptor. I've been trying to do this
>>>>>> using black magic involving TreeViewer.setCellEditors() and
>>>>>> setCellModifiers(), but unfortunately, I can't seem get the right
>>>>>> CellEditors at creation of the editor (since they depend on having
>>>>>> an instantiated ItemProvider).
>>>>>>
>>>>>> I kind of figured that the alternative to doing this was to
>>>>>> populate the columns with TreeItems, in the hope that the editors
>>>>>> would automagically be the right ones (likely through calls to
>>>>>> TreeEditor.setEditor(control, item, int)). I figured the path to
>>>>>> creating the items would be via a ContentProvider. The current
>>>>>> ITreeItemContentProvider creates TreeItems for the first
>>>>>> column (the tree), but I need to make it make it create them in the
>>>>>> other columns.
>>>>>>
>>>>>> I'm new to the whole framework, so I'll bow to advice on this, but it
>>>>>> seems to me like there might need to be an extension of
>>>>>> ITreeContentProvider (or some interface in that hierarchy) which
>>>>>> provides additional methods "hasColumnChildren()" and
>>>>>> "getColumnChildren()" (alternatively, follow the analogue of
>>>>>> TableLabelProvider and have "getColumnItem(int columnIndex)").
>>>>>> Then, the
>>>>>> class that calls this (best I can tell, currently TreeViewer, so
>>>>>> probably an extension of TreeViewer) needs to pick this up when it
>>>>>> does
>>>>>> redraw, etc.
>>>>>>
>>>>>> So I've been thinking about two directions of attack:
>>>>>> - no content provider magic, just fiddling with celleditors and
>>>>>> cellmodifiers during creation of the viewer
>>>>>> - content provider changes in order to populate the tree with
>>>>>> TreeItems so that I can then link TreeItems to appropriate editors.
>>>>>>
>>>>>
>>>>> The new JFace-3.3 API comes to rescue for you :-) Take a look at
>>>>> the whole new class infrastructure we provide.
>>>>>
>>>>> - TreeViewerColumn
>>>>> - ColumnLabelProvider
>>>> I imagine that one way to use this column label provider with EMF's
>>>> item providers is that it would know the column index and could
>>>> delegate to EMF's item providers support for
>>>> ITableItemLabelProvider. Does that make sense?
>>>
>>> Well JFace internally is completely built upon ColumnLabelProvider (=
>>> we are doing it the other way round mapping ITableLabelProvider
>>> internally to ColumnLabelProviders we attach to
>>> Table/TreeViewerColumn-s). See below for my ideas how EMF generated
>>> Viewers could work in future :-)
>> This would seem to imply having a separate set of item providers for
>> each column, rather than a single one for dealing with the whole
>> table. Maybe that's okay...
>>>
>>> The same happens to CellModifier and friends to support editing they
>>> are mapped to EditingSupport-Instances.
>> So the column just knows what aspect of the object it's editing. That
>> makes sense.
>>>
>>>>> - EditingSupport
>>>>>
>>>>> If you look very close to EditingSupport you'll notice the method
>>>>> getCellEditor(Object). This API has the big advantage that you can
>>>>> decide which Editor to show base on the object-type in front of you.
>>>> EMF's support generally relies on knowing the object of the row, but
>>>> I think this will be the object of the cell. Is that right?
>>>
>>> No it's the object of the row. We completely abondon the notion of
>>> indices because a EditingSupport/ColumnLabelProvider is directly
>>> attached to the TableViewerColumn.
>>>
>>> The reason is simply reusage of LabelProviders and
>>> EditingSupport-Objects. In former days reusage of CellModifier and
>>> I*LabelProviders wasn't possible. Say in one part of your application
>>> your had:
>>>
>>> -------------------------------------
>>> | NAME | BIRTH | STREET |
>>> -------------------------------------
>>>
>>> in the other one
>>> ---------------------------
>>> | BIRTH | NAME |
>>> ---------------------------
>>>
>>> and in the last you have
>>> ------------------------
>>> | NAME | STREET |
>>> ------------------------
>>>
>>>
>>> With the new API you have to following objects you reuse all over:
>>>
>>> --------8<--------
>>> PersonNameLabelProvider extends ColumnLabelProvider
>>> PersonNameEditingSupport extends EditingSupport
>>>
>>> PersonBirthLabelProvider extends ColumnLabelProvider
>>> PersonBirthEditingSupport extends EditingSupport
>>>
>>> PersonStreetLabelProvider extends ColumnLabelProvider
>>> PersonStreetEditingSupport extends EditingSupport
>>> --------8<--------
>>>
>>> Reusable all over ;-)
>> I can still imagine having an item provider that knows about all the
>> various columns it could support where the column index is just a
>> "key" rather than really indicating a column number and then having a
>> label provider that delegates the column labels to the appropriate
>> key. (One of the nice things about Eclipse is it's ever progressing
>> and improving, but that also means there are getting to be an awful
>> lot of different ways to do the same thing.)
>>>
>>> Infact you could say when going the brute-force way that you could
>>> generated a ColumnLabelProvider / EditingSupport for every attribute
>>> displayed/edited or for general purpose an ColumnLabelProvider /
>>> EditingSupport for every object type in your attribute:
>> That's what I was imagining. :-P
>>>
>>> --------8<--------
>>> StringLabelProvider extends ColumnLabelProvider
>>> StringEditingSupport extends EditingSupport
>>>
>>> DateLabelProvider extends ColumnLabelProvider
>>> DateEditingSupport extends EditingSupport
>>> --------8<--------
>>>
>>> I didn't had time in 3.4 to address generic sorting but if we also
>>> attach this to the ViewerColumn EMF could generate even
>>> StandardSorters :-)
>>>
>>> Now connect all this with Databinding which is also doable with the
>>> 3.3 API and you even get validation, ... .
>> It's sure hard to keep up with you guys!
>>>
>>> Tom
>>>
>
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
| Re: AdapterFactoryTableTreeEditor status [message #417156 is a reply to message #417154] |
Thu, 28 February 2008 11:06 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Tom/Jim,
Yes, let's open up a new bugzilla where we can share the full exported
project zip as a working example to drive whatever framework changes are
needed to support this better. It's an interesting idea to make the
columns by default be the properties (as in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=207324). I wish this BoF
didn't overlap with the other modeling one... :-(
Tom Schindl wrote:
> Hi Jim,
>
> It would be great if you could send me the packaged project or even
> better let's create a bugzilla where we can discuss adoption of JFace
> 3.3 in EMF generated editors (this could be one of the topics we can
> beside discuss on the "EclipseCon - BoF - UI Component Programming
> Best Practices (SWT, Nebula, JFace, Databinding ...)").
>
> Tom
>
> Jim Steel schrieb:
>>
>> G'day Tom, Ed,
>>
>> I've been working through an example. Attached is a metamodel
>> hierarchy.ecore and a modified HierarchyEditor.java, based on my
>> understanding of what Tom was talking about. I also made changes to
>> have the ItemProviders implement ITableItemLabelProvider and delegate
>> getColumnImage() and getColumnText() off to the property descriptors.
>> (I'm happy to send these, or an archived version of the whole
>> shebang, if that is useful).
>>
>> Perhaps this can serve to help any discussion about whether any
>> infrastructure classes (like AdapterFactoryTableTreeEditor was) need
>> updating in light of the JFace 3.3 stuff.
>>
>> Feedback is also welcome, as this is essentially the approach I'm
>> using for my "real" editor.
>>
>> Cheers,
>>
>> Jim.
>>
>>
>>
>>
>> Ed Merks wrote:
>>> Tom,
>>>
>>> Comments below.
>>>
>>> Tom Schindl wrote:
>>>> Ed Merks schrieb:
>>>>> Tom,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Tom Schindl wrote:
>>>>>> Jim Steel schrieb:
>>>>>>> Ed Merks wrote:
>>>>>>>> Jim,
>>>>>>>>
>>>>>>>> Comments below.
>>>>>>>>
>>>>>>>> Jim Steel wrote:
>>>>>>>>> Hi Ed,
>>>>>>>>>
>>>>>>>>> Thanks for the reply - I was afraid you might say that. You're
>>>>>>>>> quite right, that AdapterFactoryTreeEditor seems to be the way
>>>>>>>>> to go, but AdapterFactoryTableTreeEditor had a whole of stuff
>>>>>>>>> built in to handle cells in other columns, that isn't there in
>>>>>>>>> the more basic AdapterFactoryTreeEditor.
>>>>>>>> To be honest, I haven't given it any thought at all. I suspect
>>>>>>>> your right that AdapterFactoryTreeEditor needs some attention
>>>>>>>> to support columns directly. If you open a bugzilla feature
>>>>>>>> request for this and help with at least producing some test
>>>>>>>> cases I can work with you to try to get the necessary support
>>>>>>>> in place for it.
>>>>>>>
>>>>>>> I'm happy to do that.
>>>>>>>
>>>>>>>>>
>>>>>>>>> For example, I'm struggling at the moment with how to populate
>>>>>>>>> the cells in other columns with TreeItems. Presumably I need
>>>>>>>>> to modify the ItemProvider to create them somehow, but I'm
>>>>>>>>> really lost as to where I do that. Inheriting from
>>>>>>>>> ITableItemLabelProvider makes it really easy for text and
>>>>>>>>> image, but there doesn't seem to be an equivalent table
>>>>>>>>> content provider.
>>>>>>>> I'm not sure what you mean by this. The content provider just
>>>>>>>> determines the rows in the table while the label providers
>>>>>>>> determine what's displayed in the columns...
>>>>>>>
>>>>>>> Yes, the label providers determine what is displayed in the
>>>>>>> columns - I
>>>>>>> have implemented TableLabelItemProvider, and can see all the
>>>>>>> things I
>>>>>>> want to see in the other columns. However, I want to be able to
>>>>>>> edit the
>>>>>>> values. I can do this by associating basic vanilla celleditors
>>>>>>> with the columns, but I'd really like to have the celleditors
>>>>>>> that are appropriate to the property I'm editing - the
>>>>>>> celleditors generated by the PropertyDescriptor. I've been
>>>>>>> trying to do this using black magic involving
>>>>>>> TreeViewer.setCellEditors() and setCellModifiers(), but
>>>>>>> unfortunately, I can't seem get the right CellEditors at
>>>>>>> creation of the editor (since they depend on having an
>>>>>>> instantiated ItemProvider).
>>>>>>>
>>>>>>> I kind of figured that the alternative to doing this was to
>>>>>>> populate the columns with TreeItems, in the hope that the
>>>>>>> editors would automagically be the right ones (likely through
>>>>>>> calls to TreeEditor.setEditor(control, item, int)). I figured
>>>>>>> the path to creating the items would be via a ContentProvider.
>>>>>>> The current ITreeItemContentProvider creates TreeItems for the
>>>>>>> first
>>>>>>> column (the tree), but I need to make it make it create them in the
>>>>>>> other columns.
>>>>>>>
>>>>>>> I'm new to the whole framework, so I'll bow to advice on this,
>>>>>>> but it
>>>>>>> seems to me like there might need to be an extension of
>>>>>>> ITreeContentProvider (or some interface in that hierarchy) which
>>>>>>> provides additional methods "hasColumnChildren()" and
>>>>>>> "getColumnChildren()" (alternatively, follow the analogue of
>>>>>>> TableLabelProvider and have "getColumnItem(int columnIndex)").
>>>>>>> Then, the
>>>>>>> class that calls this (best I can tell, currently TreeViewer, so
>>>>>>> probably an extension of TreeViewer) needs to pick this up when
>>>>>>> it does
>>>>>>> redraw, etc.
>>>>>>>
>>>>>>> So I've been thinking about two directions of attack:
>>>>>>> - no content provider magic, just fiddling with celleditors and
>>>>>>> cellmodifiers during creation of the viewer
>>>>>>> - content provider changes in order to populate the tree with
>>>>>>> TreeItems so that I can then link TreeItems to appropriate editors.
>>>>>>>
>>>>>>
>>>>>> The new JFace-3.3 API comes to rescue for you :-) Take a look at
>>>>>> the whole new class infrastructure we provide.
>>>>>>
>>>>>> - TreeViewerColumn
>>>>>> - ColumnLabelProvider
>>>>> I imagine that one way to use this column label provider with
>>>>> EMF's item providers is that it would know the column index and
>>>>> could delegate to EMF's item providers support for
>>>>> ITableItemLabelProvider. Does that make sense?
>>>>
>>>> Well JFace internally is completely built upon ColumnLabelProvider
>>>> (= we are doing it the other way round mapping ITableLabelProvider
>>>> internally to ColumnLabelProviders we attach to
>>>> Table/TreeViewerColumn-s). See below for my ideas how EMF generated
>>>> Viewers could work in future :-)
>>> This would seem to imply having a separate set of item providers for
>>> each column, rather than a single one for dealing with the whole
>>> table. Maybe that's okay...
>>>>
>>>> The same happens to CellModifier and friends to support editing
>>>> they are mapped to EditingSupport-Instances.
>>> So the column just knows what aspect of the object it's editing.
>>> That makes sense.
>>>>
>>>>>> - EditingSupport
>>>>>>
>>>>>> If you look very close to EditingSupport you'll notice the method
>>>>>> getCellEditor(Object). This API has the big advantage that you
>>>>>> can decide which Editor to show base on the object-type in front
>>>>>> of you.
>>>>> EMF's support generally relies on knowing the object of the row,
>>>>> but I think this will be the object of the cell. Is that right?
>>>>
>>>> No it's the object of the row. We completely abondon the notion of
>>>> indices because a EditingSupport/ColumnLabelProvider is directly
>>>> attached to the TableViewerColumn.
>>>>
>>>> The reason is simply reusage of LabelProviders and
>>>> EditingSupport-Objects. In former days reusage of CellModifier and
>>>> I*LabelProviders wasn't possible. Say in one part of your
>>>> application your had:
>>>>
>>>> -------------------------------------
>>>> | NAME | BIRTH | STREET |
>>>> -------------------------------------
>>>>
>>>> in the other one
>>>> ---------------------------
>>>> | BIRTH | NAME |
>>>> ---------------------------
>>>>
>>>> and in the last you have
>>>> ------------------------
>>>> | NAME | STREET |
>>>> ------------------------
>>>>
>>>>
>>>> With the new API you have to following objects you reuse all over:
>>>>
>>>> --------8<--------
>>>> PersonNameLabelProvider extends ColumnLabelProvider
>>>> PersonNameEditingSupport extends EditingSupport
>>>>
>>>> PersonBirthLabelProvider extends ColumnLabelProvider
>>>> PersonBirthEditingSupport extends EditingSupport
>>>>
>>>> PersonStreetLabelProvider extends ColumnLabelProvider
>>>> PersonStreetEditingSupport extends EditingSupport
>>>> --------8<--------
>>>>
>>>> Reusable all over ;-)
>>> I can still imagine having an item provider that knows about all the
>>> various columns it could support where the column index is just a
>>> "key" rather than really indicating a column number and then having
>>> a label provider that delegates the column labels to the appropriate
>>> key. (One of the nice things about Eclipse is it's ever progressing
>>> and improving, but that also means there are getting to be an awful
>>> lot of different ways to do the same thing.)
>>>>
>>>> Infact you could say when going the brute-force way that you could
>>>> generated a ColumnLabelProvider / EditingSupport for every
>>>> attribute displayed/edited or for general purpose an
>>>> ColumnLabelProvider / EditingSupport for every object type in your
>>>> attribute:
>>> That's what I was imagining. :-P
>>>>
>>>> --------8<--------
>>>> StringLabelProvider extends ColumnLabelProvider
>>>> StringEditingSupport extends EditingSupport
>>>>
>>>> DateLabelProvider extends ColumnLabelProvider
>>>> DateEditingSupport extends EditingSupport
>>>> --------8<--------
>>>>
>>>> I didn't had time in 3.4 to address generic sorting but if we also
>>>> attach this to the ViewerColumn EMF could generate even
>>>> StandardSorters :-)
>>>>
>>>> Now connect all this with Databinding which is also doable with the
>>>> 3.3 API and you even get validation, ... .
>>> It's sure hard to keep up with you guys!
>>>>
>>>> Tom
>>>>
>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: AdapterFactoryTableTreeEditor status [message #417188 is a reply to message #417156] |
Thu, 28 February 2008 22:57 |
Jim Steel
Messages: 54
Registered: July 2009 |
Member |
|
|
Lodged as bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=220843
It has an example zip file attached with a model, edit, and editor
project. The example is simple (e.g. presently only one class uses the
columns, which is an important simplification).
I would welcome feedback, either on the way I use EMF, or on the way I
use JFace. For example, for the moment I essentially have only one label
provider, whereas an alternative might be to somehow have one label
provider per column.
Cheers,
Jim.
Ed Merks wrote:
> Tom/Jim,
>
> Yes, let's open up a new bugzilla where we can share the full exported
> project zip as a working example to drive whatever framework changes are
> needed to support this better. It's an interesting idea to make the
> columns by default be the properties (as in
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=207324). I wish this BoF
> didn't overlap with the other modeling one... :-(
>
>
> Tom Schindl wrote:
>> Hi Jim,
>>
>> It would be great if you could send me the packaged project or even
>> better let's create a bugzilla where we can discuss adoption of JFace
>> 3.3 in EMF generated editors (this could be one of the topics we can
>> beside discuss on the "EclipseCon - BoF - UI Component Programming
>> Best Practices (SWT, Nebula, JFace, Databinding ...)").
>>
>> Tom
>>
>> Jim Steel schrieb:
>>>
>>> G'day Tom, Ed,
>>>
>>> I've been working through an example. Attached is a metamodel
>>> hierarchy.ecore and a modified HierarchyEditor.java, based on my
>>> understanding of what Tom was talking about. I also made changes to
>>> have the ItemProviders implement ITableItemLabelProvider and delegate
>>> getColumnImage() and getColumnText() off to the property descriptors.
>>> (I'm happy to send these, or an archived version of the whole
>>> shebang, if that is useful).
>>>
>>> Perhaps this can serve to help any discussion about whether any
>>> infrastructure classes (like AdapterFactoryTableTreeEditor was) need
>>> updating in light of the JFace 3.3 stuff.
>>>
>>> Feedback is also welcome, as this is essentially the approach I'm
>>> using for my "real" editor.
>>>
>>> Cheers,
>>>
>>> Jim.
>>>
>>>
>>>
>>>
>>> Ed Merks wrote:
>>>> Tom,
>>>>
>>>> Comments below.
>>>>
>>>> Tom Schindl wrote:
>>>>> Ed Merks schrieb:
>>>>>> Tom,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>> Tom Schindl wrote:
>>>>>>> Jim Steel schrieb:
>>>>>>>> Ed Merks wrote:
>>>>>>>>> Jim,
>>>>>>>>>
>>>>>>>>> Comments below.
>>>>>>>>>
>>>>>>>>> Jim Steel wrote:
>>>>>>>>>> Hi Ed,
>>>>>>>>>>
>>>>>>>>>> Thanks for the reply - I was afraid you might say that. You're
>>>>>>>>>> quite right, that AdapterFactoryTreeEditor seems to be the way
>>>>>>>>>> to go, but AdapterFactoryTableTreeEditor had a whole of stuff
>>>>>>>>>> built in to handle cells in other columns, that isn't there in
>>>>>>>>>> the more basic AdapterFactoryTreeEditor.
>>>>>>>>> To be honest, I haven't given it any thought at all. I suspect
>>>>>>>>> your right that AdapterFactoryTreeEditor needs some attention
>>>>>>>>> to support columns directly. If you open a bugzilla feature
>>>>>>>>> request for this and help with at least producing some test
>>>>>>>>> cases I can work with you to try to get the necessary support
>>>>>>>>> in place for it.
>>>>>>>>
>>>>>>>> I'm happy to do that.
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> For example, I'm struggling at the moment with how to populate
>>>>>>>>>> the cells in other columns with TreeItems. Presumably I need
>>>>>>>>>> to modify the ItemProvider to create them somehow, but I'm
>>>>>>>>>> really lost as to where I do that. Inheriting from
>>>>>>>>>> ITableItemLabelProvider makes it really easy for text and
>>>>>>>>>> image, but there doesn't seem to be an equivalent table
>>>>>>>>>> content provider.
>>>>>>>>> I'm not sure what you mean by this. The content provider just
>>>>>>>>> determines the rows in the table while the label providers
>>>>>>>>> determine what's displayed in the columns...
>>>>>>>>
>>>>>>>> Yes, the label providers determine what is displayed in the
>>>>>>>> columns - I
>>>>>>>> have implemented TableLabelItemProvider, and can see all the
>>>>>>>> things I
>>>>>>>> want to see in the other columns. However, I want to be able to
>>>>>>>> edit the
>>>>>>>> values. I can do this by associating basic vanilla celleditors
>>>>>>>> with the columns, but I'd really like to have the celleditors
>>>>>>>> that are appropriate to the property I'm editing - the
>>>>>>>> celleditors generated by the PropertyDescriptor. I've been
>>>>>>>> trying to do this using black magic involving
>>>>>>>> TreeViewer.setCellEditors() and setCellModifiers(), but
>>>>>>>> unfortunately, I can't seem get the right CellEditors at
>>>>>>>> creation of the editor (since they depend on having an
>>>>>>>> instantiated ItemProvider).
>>>>>>>>
>>>>>>>> I kind of figured that the alternative to doing this was to
>>>>>>>> populate the columns with TreeItems, in the hope that the
>>>>>>>> editors would automagically be the right ones (likely through
>>>>>>>> calls to TreeEditor.setEditor(control, item, int)). I figured
>>>>>>>> the path to creating the items would be via a ContentProvider.
>>>>>>>> The current ITreeItemContentProvider creates TreeItems for the
>>>>>>>> first
>>>>>>>> column (the tree), but I need to make it make it create them in the
>>>>>>>> other columns.
>>>>>>>>
>>>>>>>> I'm new to the whole framework, so I'll bow to advice on this,
>>>>>>>> but it
>>>>>>>> seems to me like there might need to be an extension of
>>>>>>>> ITreeContentProvider (or some interface in that hierarchy) which
>>>>>>>> provides additional methods "hasColumnChildren()" and
>>>>>>>> "getColumnChildren()" (alternatively, follow the analogue of
>>>>>>>> TableLabelProvider and have "getColumnItem(int columnIndex)").
>>>>>>>> Then, the
>>>>>>>> class that calls this (best I can tell, currently TreeViewer, so
>>>>>>>> probably an extension of TreeViewer) needs to pick this up when
>>>>>>>> it does
>>>>>>>> redraw, etc.
>>>>>>>>
>>>>>>>> So I've been thinking about two directions of attack:
>>>>>>>> - no content provider magic, just fiddling with celleditors and
>>>>>>>> cellmodifiers during creation of the viewer
>>>>>>>> - content provider changes in order to populate the tree with
>>>>>>>> TreeItems so that I can then link TreeItems to appropriate editors.
>>>>>>>>
>>>>>>>
>>>>>>> The new JFace-3.3 API comes to rescue for you :-) Take a look at
>>>>>>> the whole new class infrastructure we provide.
>>>>>>>
>>>>>>> - TreeViewerColumn
>>>>>>> - ColumnLabelProvider
>>>>>> I imagine that one way to use this column label provider with
>>>>>> EMF's item providers is that it would know the column index and
>>>>>> could delegate to EMF's item providers support for
>>>>>> ITableItemLabelProvider. Does that make sense?
>>>>>
>>>>> Well JFace internally is completely built upon ColumnLabelProvider
>>>>> (= we are doing it the other way round mapping ITableLabelProvider
>>>>> internally to ColumnLabelProviders we attach to
>>>>> Table/TreeViewerColumn-s). See below for my ideas how EMF generated
>>>>> Viewers could work in future :-)
>>>> This would seem to imply having a separate set of item providers for
>>>> each column, rather than a single one for dealing with the whole
>>>> table. Maybe that's okay...
>>>>>
>>>>> The same happens to CellModifier and friends to support editing
>>>>> they are mapped to EditingSupport-Instances.
>>>> So the column just knows what aspect of the object it's editing.
>>>> That makes sense.
>>>>>
>>>>>>> - EditingSupport
>>>>>>>
>>>>>>> If you look very close to EditingSupport you'll notice the method
>>>>>>> getCellEditor(Object). This API has the big advantage that you
>>>>>>> can decide which Editor to show base on the object-type in front
>>>>>>> of you.
>>>>>> EMF's support generally relies on knowing the object of the row,
>>>>>> but I think this will be the object of the cell. Is that right?
>>>>>
>>>>> No it's the object of the row. We completely abondon the notion of
>>>>> indices because a EditingSupport/ColumnLabelProvider is directly
>>>>> attached to the TableViewerColumn.
>>>>>
>>>>> The reason is simply reusage of LabelProviders and
>>>>> EditingSupport-Objects. In former days reusage of CellModifier and
>>>>> I*LabelProviders wasn't possible. Say in one part of your
>>>>> application your had:
>>>>>
>>>>> -------------------------------------
>>>>> | NAME | BIRTH | STREET |
>>>>> -------------------------------------
>>>>>
>>>>> in the other one
>>>>> ---------------------------
>>>>> | BIRTH | NAME |
>>>>> ---------------------------
>>>>>
>>>>> and in the last you have
>>>>> ------------------------
>>>>> | NAME | STREET |
>>>>> ------------------------
>>>>>
>>>>>
>>>>> With the new API you have to following objects you reuse all over:
>>>>>
>>>>> --------8<--------
>>>>> PersonNameLabelProvider extends ColumnLabelProvider
>>>>> PersonNameEditingSupport extends EditingSupport
>>>>>
>>>>> PersonBirthLabelProvider extends ColumnLabelProvider
>>>>> PersonBirthEditingSupport extends EditingSupport
>>>>>
>>>>> PersonStreetLabelProvider extends ColumnLabelProvider
>>>>> PersonStreetEditingSupport extends EditingSupport
>>>>> --------8<--------
>>>>>
>>>>> Reusable all over ;-)
>>>> I can still imagine having an item provider that knows about all the
>>>> various columns it could support where the column index is just a
>>>> "key" rather than really indicating a column number and then having
>>>> a label provider that delegates the column labels to the appropriate
>>>> key. (One of the nice things about Eclipse is it's ever progressing
>>>> and improving, but that also means there are getting to be an awful
>>>> lot of different ways to do the same thing.)
>>>>>
>>>>> Infact you could say when going the brute-force way that you could
>>>>> generated a ColumnLabelProvider / EditingSupport for every
>>>>> attribute displayed/edited or for general purpose an
>>>>> ColumnLabelProvider / EditingSupport for every object type in your
>>>>> attribute:
>>>> That's what I was imagining. :-P
>>>>>
>>>>> --------8<--------
>>>>> StringLabelProvider extends ColumnLabelProvider
>>>>> StringEditingSupport extends EditingSupport
>>>>>
>>>>> DateLabelProvider extends ColumnLabelProvider
>>>>> DateEditingSupport extends EditingSupport
>>>>> --------8<--------
>>>>>
>>>>> I didn't had time in 3.4 to address generic sorting but if we also
>>>>> attach this to the ViewerColumn EMF could generate even
>>>>> StandardSorters :-)
>>>>>
>>>>> Now connect all this with Databinding which is also doable with the
>>>>> 3.3 API and you even get validation, ... .
>>>> It's sure hard to keep up with you guys!
>>>>>
>>>>> Tom
>>>>>
>>>
>>
>>
|
|
| | |
| Re: AdapterFactoryTableTreeEditor status [message #417199 is a reply to message #417188] |
Fri, 29 February 2008 11:52 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Jim,
Thanks. I'll try to have a look at it today. We can continue
discussions on the bugzilla.
Jim Steel wrote:
>
> Lodged as bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=220843
>
> It has an example zip file attached with a model, edit, and editor
> project. The example is simple (e.g. presently only one class uses the
> columns, which is an important simplification).
>
> I would welcome feedback, either on the way I use EMF, or on the way I
> use JFace. For example, for the moment I essentially have only one
> label provider, whereas an alternative might be to somehow have one
> label provider per column.
>
> Cheers,
>
> Jim.
>
>
>
> Ed Merks wrote:
>> Tom/Jim,
>>
>> Yes, let's open up a new bugzilla where we can share the full
>> exported project zip as a working example to drive whatever framework
>> changes are needed to support this better. It's an interesting idea
>> to make the columns by default be the properties (as in
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=207324). I wish this
>> BoF didn't overlap with the other modeling one... :-(
>>
>>
>> Tom Schindl wrote:
>>> Hi Jim,
>>>
>>> It would be great if you could send me the packaged project or even
>>> better let's create a bugzilla where we can discuss adoption of
>>> JFace 3.3 in EMF generated editors (this could be one of the topics
>>> we can beside discuss on the "EclipseCon - BoF - UI Component
>>> Programming Best Practices (SWT, Nebula, JFace, Databinding ...)").
>>>
>>> Tom
>>>
>>> Jim Steel schrieb:
>>>>
>>>> G'day Tom, Ed,
>>>>
>>>> I've been working through an example. Attached is a metamodel
>>>> hierarchy.ecore and a modified HierarchyEditor.java, based on my
>>>> understanding of what Tom was talking about. I also made changes to
>>>> have the ItemProviders implement ITableItemLabelProvider and
>>>> delegate getColumnImage() and getColumnText() off to the property
>>>> descriptors. (I'm happy to send these, or an archived version of
>>>> the whole shebang, if that is useful).
>>>>
>>>> Perhaps this can serve to help any discussion about whether any
>>>> infrastructure classes (like AdapterFactoryTableTreeEditor was)
>>>> need updating in light of the JFace 3.3 stuff.
>>>>
>>>> Feedback is also welcome, as this is essentially the approach I'm
>>>> using for my "real" editor.
>>>>
>>>> Cheers,
>>>>
>>>> Jim.
>>>>
>>>>
>>>>
>>>>
>>>> Ed Merks wrote:
>>>>> Tom,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Tom Schindl wrote:
>>>>>> Ed Merks schrieb:
>>>>>>> Tom,
>>>>>>>
>>>>>>> Comments below.
>>>>>>>
>>>>>>> Tom Schindl wrote:
>>>>>>>> Jim Steel schrieb:
>>>>>>>>> Ed Merks wrote:
>>>>>>>>>> Jim,
>>>>>>>>>>
>>>>>>>>>> Comments below.
>>>>>>>>>>
>>>>>>>>>> Jim Steel wrote:
>>>>>>>>>>> Hi Ed,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for the reply - I was afraid you might say that.
>>>>>>>>>>> You're quite right, that AdapterFactoryTreeEditor seems to
>>>>>>>>>>> be the way to go, but AdapterFactoryTableTreeEditor had a
>>>>>>>>>>> whole of stuff built in to handle cells in other columns,
>>>>>>>>>>> that isn't there in the more basic AdapterFactoryTreeEditor.
>>>>>>>>>> To be honest, I haven't given it any thought at all. I
>>>>>>>>>> suspect your right that AdapterFactoryTreeEditor needs some
>>>>>>>>>> attention to support columns directly. If you open a
>>>>>>>>>> bugzilla feature request for this and help with at least
>>>>>>>>>> producing some test cases I can work with you to try to get
>>>>>>>>>> the necessary support in place for it.
>>>>>>>>>
>>>>>>>>> I'm happy to do that.
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> For example, I'm struggling at the moment with how to
>>>>>>>>>>> populate the cells in other columns with TreeItems.
>>>>>>>>>>> Presumably I need to modify the ItemProvider to create them
>>>>>>>>>>> somehow, but I'm really lost as to where I do that.
>>>>>>>>>>> Inheriting from ITableItemLabelProvider makes it really easy
>>>>>>>>>>> for text and image, but there doesn't seem to be an
>>>>>>>>>>> equivalent table content provider.
>>>>>>>>>> I'm not sure what you mean by this. The content provider
>>>>>>>>>> just determines the rows in the table while the label
>>>>>>>>>> providers determine what's displayed in the columns...
>>>>>>>>>
>>>>>>>>> Yes, the label providers determine what is displayed in the
>>>>>>>>> columns - I
>>>>>>>>> have implemented TableLabelItemProvider, and can see all the
>>>>>>>>> things I
>>>>>>>>> want to see in the other columns. However, I want to be able
>>>>>>>>> to edit the
>>>>>>>>> values. I can do this by associating basic vanilla celleditors
>>>>>>>>> with the columns, but I'd really like to have the celleditors
>>>>>>>>> that are appropriate to the property I'm editing - the
>>>>>>>>> celleditors generated by the PropertyDescriptor. I've been
>>>>>>>>> trying to do this using black magic involving
>>>>>>>>> TreeViewer.setCellEditors() and setCellModifiers(), but
>>>>>>>>> unfortunately, I can't seem get the right CellEditors at
>>>>>>>>> creation of the editor (since they depend on having an
>>>>>>>>> instantiated ItemProvider).
>>>>>>>>>
>>>>>>>>> I kind of figured that the alternative to doing this was to
>>>>>>>>> populate the columns with TreeItems, in the hope that the
>>>>>>>>> editors would automagically be the right ones (likely through
>>>>>>>>> calls to TreeEditor.setEditor(control, item, int)). I figured
>>>>>>>>> the path to creating the items would be via a ContentProvider.
>>>>>>>>> The current ITreeItemContentProvider creates TreeItems for the
>>>>>>>>> first
>>>>>>>>> column (the tree), but I need to make it make it create them
>>>>>>>>> in the
>>>>>>>>> other columns.
>>>>>>>>>
>>>>>>>>> I'm new to the whole framework, so I'll bow to advice on this,
>>>>>>>>> but it
>>>>>>>>> seems to me like there might need to be an extension of
>>>>>>>>> ITreeContentProvider (or some interface in that hierarchy) which
>>>>>>>>> provides additional methods "hasColumnChildren()" and
>>>>>>>>> "getColumnChildren()" (alternatively, follow the analogue of
>>>>>>>>> TableLabelProvider and have "getColumnItem(int columnIndex)").
>>>>>>>>> Then, the
>>>>>>>>> class that calls this (best I can tell, currently TreeViewer, so
>>>>>>>>> probably an extension of TreeViewer) needs to pick this up
>>>>>>>>> when it does
>>>>>>>>> redraw, etc.
>>>>>>>>>
>>>>>>>>> So I've been thinking about two directions of attack:
>>>>>>>>> - no content provider magic, just fiddling with celleditors
>>>>>>>>> and cellmodifiers during creation of the viewer
>>>>>>>>> - content provider changes in order to populate the tree with
>>>>>>>>> TreeItems so that I can then link TreeItems to appropriate
>>>>>>>>> editors.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The new JFace-3.3 API comes to rescue for you :-) Take a look
>>>>>>>> at the whole new class infrastructure we provide.
>>>>>>>>
>>>>>>>> - TreeViewerColumn
>>>>>>>> - ColumnLabelProvider
>>>>>>> I imagine that one way to use this column label provider with
>>>>>>> EMF's item providers is that it would know the column index and
>>>>>>> could delegate to EMF's item providers support for
>>>>>>> ITableItemLabelProvider. Does that make sense?
>>>>>>
>>>>>> Well JFace internally is completely built upon
>>>>>> ColumnLabelProvider (= we are doing it the other way round
>>>>>> mapping ITableLabelProvider internally to ColumnLabelProviders we
>>>>>> attach to Table/TreeViewerColumn-s). See below for my ideas how
>>>>>> EMF generated Viewers could work in future :-)
>>>>> This would seem to imply having a separate set of item providers
>>>>> for each column, rather than a single one for dealing with the
>>>>> whole table. Maybe that's okay...
>>>>>>
>>>>>> The same happens to CellModifier and friends to support editing
>>>>>> they are mapped to EditingSupport-Instances.
>>>>> So the column just knows what aspect of the object it's editing.
>>>>> That makes sense.
>>>>>>
>>>>>>>> - EditingSupport
>>>>>>>>
>>>>>>>> If you look very close to EditingSupport you'll notice the
>>>>>>>> method getCellEditor(Object). This API has the big advantage
>>>>>>>> that you can decide which Editor to show base on the
>>>>>>>> object-type in front of you.
>>>>>>> EMF's support generally relies on knowing the object of the row,
>>>>>>> but I think this will be the object of the cell. Is that right?
>>>>>>
>>>>>> No it's the object of the row. We completely abondon the notion
>>>>>> of indices because a EditingSupport/ColumnLabelProvider is
>>>>>> directly attached to the TableViewerColumn.
>>>>>>
>>>>>> The reason is simply reusage of LabelProviders and
>>>>>> EditingSupport-Objects. In former days reusage of CellModifier
>>>>>> and I*LabelProviders wasn't possible. Say in one part of your
>>>>>> application your had:
>>>>>>
>>>>>> -------------------------------------
>>>>>> | NAME | BIRTH | STREET |
>>>>>> -------------------------------------
>>>>>>
>>>>>> in the other one
>>>>>> ---------------------------
>>>>>> | BIRTH | NAME |
>>>>>> ---------------------------
>>>>>>
>>>>>> and in the last you have
>>>>>> ------------------------
>>>>>> | NAME | STREET |
>>>>>> ------------------------
>>>>>>
>>>>>>
>>>>>> With the new API you have to following objects you reuse all over:
>>>>>>
>>>>>> --------8<--------
>>>>>> PersonNameLabelProvider extends ColumnLabelProvider
>>>>>> PersonNameEditingSupport extends EditingSupport
>>>>>>
>>>>>> PersonBirthLabelProvider extends ColumnLabelProvider
>>>>>> PersonBirthEditingSupport extends EditingSupport
>>>>>>
>>>>>> PersonStreetLabelProvider extends ColumnLabelProvider
>>>>>> PersonStreetEditingSupport extends EditingSupport
>>>>>> --------8<--------
>>>>>>
>>>>>> Reusable all over ;-)
>>>>> I can still imagine having an item provider that knows about all
>>>>> the various columns it could support where the column index is
>>>>> just a "key" rather than really indicating a column number and
>>>>> then having a label provider that delegates the column labels to
>>>>> the appropriate key. (One of the nice things about Eclipse is
>>>>> it's ever progressing and improving, but that also means there are
>>>>> getting to be an awful lot of different ways to do the same thing.)
>>>>>>
>>>>>> Infact you could say when going the brute-force way that you
>>>>>> could generated a ColumnLabelProvider / EditingSupport for every
>>>>>> attribute displayed/edited or for general purpose an
>>>>>> ColumnLabelProvider / EditingSupport for every object type in
>>>>>> your attribute:
>>>>> That's what I was imagining. :-P
>>>>>>
>>>>>> --------8<--------
>>>>>> StringLabelProvider extends ColumnLabelProvider
>>>>>> StringEditingSupport extends EditingSupport
>>>>>>
>>>>>> DateLabelProvider extends ColumnLabelProvider
>>>>>> DateEditingSupport extends EditingSupport
>>>>>> --------8<--------
>>>>>>
>>>>>> I didn't had time in 3.4 to address generic sorting but if we
>>>>>> also attach this to the ViewerColumn EMF could generate even
>>>>>> StandardSorters :-)
>>>>>>
>>>>>> Now connect all this with Databinding which is also doable with
>>>>>> the 3.3 API and you even get validation, ... .
>>>>> It's sure hard to keep up with you guys!
>>>>>>
>>>>>> Tom
>>>>>>
>>>>
>>>
>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 26 06:48:27 GMT 2024
Powered by FUDForum. Page generated in 0.05287 seconds |
] 
Search
Help
Register
Login
Home
