Eclipse Community Forums: GEF » EMF enum property editor

Home » Eclipse Projects » GEF » EMF enum property editor

EMF enum property editor [message #167242]

Sun, 06 February 2005 18:41

Eclipse User

I am trying to set up my properties view for the enums in my EMF objects
using an IPropertySource similar to the Workflow example in the RedBook.
I have managed to create a ComboBoxPropertyDescriptor with the correct
string values based on the EEnum ELiterals collection but converting
between the index wanted by descriptor and the value of the feature is
rather awkward. Is there a straightforward way to do this or do people
create their own PropertyDescriptor that handles the underlying data
type better?

Thanks,
Barry

Re: EMF enum property editor [message #167305 is a reply to message #167242]

Mon, 07 February 2005 01:46

Eclipse User

You should probably direct this to the EMF newsgroup. Or you can go through
the code and see how the EDiagram example does it (its properties are
generated by EMF).

"Barry Lay" <blay@laysercomputing.com> wrote in message
news:cu69ug$hvc$1@www.eclipse.org...
> I am trying to set up my properties view for the enums in my EMF objects
> using an IPropertySource similar to the Workflow example in the RedBook.
> I have managed to create a ComboBoxPropertyDescriptor with the correct
> string values based on the EEnum ELiterals collection but converting
> between the index wanted by descriptor and the value of the feature is
> rather awkward. Is there a straightforward way to do this or do people
> create their own PropertyDescriptor that handles the underlying data
> type better?
>
> Thanks,
> Barry

Re: EMF enum property editor [message #167312 is a reply to message #167305]

Mon, 07 February 2005 01:51

Eclipse User

Forgot to mention that the EDiagram example doesn't actually use a combo
with the possible values in a drop-down. Rather, it uses a TextCellEditor
where you can type in one of the string literals. It should answer your
question though. My suspicion is that the descriptor generated by EMF
doesn't expect an int or EInt, rather an ELiteral for that EEnum.

"Pratik Shah" <ppshah@us.ibm.com> wrote in message
news:cu72sm$255$1@www.eclipse.org...
> You should probably direct this to the EMF newsgroup. Or you can go
through
> the code and see how the EDiagram example does it (its properties are
> generated by EMF).
>
> "Barry Lay" <blay@laysercomputing.com> wrote in message
> news:cu69ug$hvc$1@www.eclipse.org...
> > I am trying to set up my properties view for the enums in my EMF objects
> > using an IPropertySource similar to the Workflow example in the RedBook.
> > I have managed to create a ComboBoxPropertyDescriptor with the correct
> > string values based on the EEnum ELiterals collection but converting
> > between the index wanted by descriptor and the value of the feature is
> > rather awkward. Is there a straightforward way to do this or do people
> > create their own PropertyDescriptor that handles the underlying data
> > type better?
> >
> > Thanks,
> > Barry
>
>

Re: EMF enum property editor [message #167356 is a reply to message #167242]

Mon, 07 February 2005 09:25

Eclipse User

You can use a LabelProvider on your ComboboxDescriptor.
When you instanciate this LabelProvider, you can give it in the
constructor the list of the correct labels and implement the getText
methods.

myCombobox.setsetLabelProvider(new MyLabelProvider(List labels));

public String getText(Object element) {
if (element instanceof Integer) {
int value = ((Integer) element).intValue();
return (String) _labels.get(value);
}
else
return super.getText(element);
}

Stephane

Barry Lay wrote:
> I am trying to set up my properties view for the enums in my EMF objects
> using an IPropertySource similar to the Workflow example in the RedBook.
> I have managed to create a ComboBoxPropertyDescriptor with the correct
> string values based on the EEnum ELiterals collection but converting
> between the index wanted by descriptor and the value of the feature is
> rather awkward. Is there a straightforward way to do this or do people
> create their own PropertyDescriptor that handles the underlying data
> type better?
>
> Thanks,
> Barry

Re: EMF enum property editor [message #167364 is a reply to message #167312]

Mon, 07 February 2005 16:11

Eclipse User

Pratik Shah wrote:
>>You should probably direct this to the EMF newsgroup. Or you can go
>
> through
>
>>the code and see how the EDiagram example does it (its properties are
>>generated by EMF).

I have noticed that the folks in the EMF newsgroup tend to direct
questions regarding GEF here. I suspect that the fact that the two
frameworks have somewhat different structures may be the reason.

I have decided to see if I can use the EMF generated providers to do the
properties. I thought at first to set the PropertySourceProvider on
GEF's UndoablePropertySheetEntry to the EMF
AdapterFactoryContentProvider, but discovered that the latter expects to
see EObjects or IPropertyProviders whereas GEF is handing it EditParts.
It doesn't recognize the IAdapter interface on the EditPart so won't
delegate. I ended up creating the EMF PropertySource in my top-level
EditPart based on the EMF ItemProviderAdapterFactory and that seems to
make the properties work. I have seen some comments about the undo/redo
actions not working properly in the list - I will have to keep an eye
out for this.

It is unfortunate that there isn't an interoperability news group where
we can discuss things like this without worrying about who is officially
responsible for the answer.

Thanks for the help anyway.

Re: EMF enum property editor [message #167384 is a reply to message #167364]

Mon, 07 February 2005 18:28

Eclipse User

Originally posted by: none.us.ibm.com

> I have noticed that the folks in the EMF newsgroup tend to direct
> questions regarding GEF here. I suspect that the fact that the two

Displaying an EMF object in the property sheet has nothing to do with GEF.
The property sheet is part of the workbench.

> frameworks have somewhat different structures may be the reason.
>
> I have decided to see if I can use the EMF generated providers to do the
> properties.

I would not design my application that way. It's straightforward to write a
propertysource implementation yourself. It is nothing but a big switch
statement.

> I thought at first to set the PropertySourceProvider on GEF's
> UndoablePropertySheetEntry to the EMF AdapterFactoryContentProvider, but
> discovered that the latter expects to see EObjects or IPropertyProviders
> whereas GEF is handing it EditParts. It doesn't recognize the IAdapter
> interface on the EditPart so won't delegate. I ended up creating the EMF
> PropertySource in my top-level EditPart based on the EMF
> ItemProviderAdapterFactory and that seems to make the properties work. I
> have seen some comments about the undo/redo actions not working properly
> in the list - I will have to keep an eye out for this.
>
> It is unfortunate that there isn't an interoperability news group where

There is a redbook on this subject.

> we can discuss things like this without worrying about who is officially
> responsible for the answer.
>
> Thanks for the help anyway.

Re: EMF enum property editor [message #167391 is a reply to message #167384]

Tue, 08 February 2005 00:53

Eclipse User

Randy Hudson wrote:

> Displaying an EMF object in the property sheet has nothing to do with GEF.

Ah, but it does. If you follow the "redbook" example and use
GEFPlugin.createUndoablePropertySheetEntry(getCommandStack() ) and set
that as the rootEntry for the property sheet page then things don't work
according to the PlugIn Guide.

Following the guide and the EMF editor example, setting the
PropertySourceProvider on the PropertySheetPage to an appropriate
content adapter should allow the EMF item provider to deliver
PropertyDescriptors for the Property view. It doesn't work because the
GEF UndoablePropertySheetEntry extends an internal GEF version of
PropertySheetEntry which is not recognized by the
setPropertySourceProvider method in PropertySheetPage. The latter
silently does nothing which provides a debugging challenge.

In my opinion it is a poor design choice to advertise that setRootEntry
on the Eclipse PropertySheetPage takes an IPropertySheetEntry but in
fact requires a bonafide PropertySheetEntry to function properly. It is
also a poor design choice on the GEF side to copy and modify the text of
an existing class (PropertySheetEntry) into an internal package without
even changing the name. You have to look at the imports to figure out
why it doesn't work.

Going past the structural nuances and calling setPropertySourceProvider
on the UndoablePropertySheetEntry still doesn't work because the EMF
AdapterFactoryContentProvider expects to be dealing with model objects,
not with GEF EditParts. In this case I suspect that the EMF provider
should respect the IAdapter aspect of the EditPart and get the job done.

This is not a simple "GEF is at fault"/"EMF is at fault" decision.
There is a problem with the way these packages cooperate within the
Eclipse framework, and I think that some curious design decisions are
making it difficult for the less experienced of us to figure out what we
are supposed to do. I am reminded of a battle I had many years ago with
the ISPF and GDDM guys within IBM on why those two products just
couldn't get along. At least we have the source code (for Eclipse)
nowadays so that we can figure it out.

>>I have decided to see if I can use the EMF generated providers to do the
>>properties.
>
>
> I would not design my application that way. It's straightforward to write a
> propertysource implementation yourself. It is nothing but a big switch
> statement.

I haven't seen any convenient mechanisms to properly handle an EEnum,
which was the basis for the original question. I can take apart the EMF
ItemPropertyDescriptor to see how it does it, but why should I be
essentially copying functionality from an existing set of code? Why
can't I just use the provider that the EMF generates for me automatically?

> There is a redbook on this subject.

The one I have been looking at is "Eclipse Development using the
Graphical Editing Framework and the Eclipse Modeling Framework",
SG24-6302. I see your name in the contributions (or someone whose name
is spelled the same as yours).

I appreciate your help. i have no axe to grind regarding the design of
any of the products I have been dealing with; I am just trying to get my
program to work.

Thanks,
Barry

Re: EMF enum property editor [message #167445 is a reply to message #167391]

Tue, 08 February 2005 11:44

Eclipse User

Originally posted by: none.us.ibm.com

"Barry Lay" <blay@laysercomputing.com> escreveu na mensagem
news:cu9k5o$e9f$1@www.eclipse.org...
> Randy Hudson wrote:
>
>> Displaying an EMF object in the property sheet has nothing to do with
>> GEF.
>
> Ah, but it does. If you follow the "redbook" example and use
> GEFPlugin.createUndoablePropertySheetEntry(getCommandStack() ) and set that
> as the rootEntry for the property sheet page then things don't work
> according to the PlugIn Guide.

Again, you are using "EMF" to mean "EMF Edit". That's like using "Draw2d" to
refer to "GEF". They are different layers in the cake. I would prefer to
implement the PropertySource myself using my own adapter.

> Following the guide and the EMF editor example, setting the
> PropertySourceProvider on the PropertySheetPage to an appropriate content
> adapter should allow the EMF item provider to deliver PropertyDescriptors
> for the Property view. It doesn't work because the GEF
> UndoablePropertySheetEntry extends an internal GEF version of
> PropertySheetEntry which is not recognized by the
> setPropertySourceProvider method in PropertySheetPage. The latter
> silently does nothing which provides a debugging challenge.

So open a bug against Platform/UI. They should not be casting to their
specific implementation.

> In my opinion it is a poor design choice to advertise that setRootEntry on
> the Eclipse PropertySheetPage takes an IPropertySheetEntry but in fact
> requires a bonafide PropertySheetEntry to function properly. It is also a
> poor design choice on the GEF side to copy and modify the text of an
> existing class (PropertySheetEntry) into an internal package without even
> changing the name. You have to look at the imports to figure out why it
> doesn't work.

I'd say that keeping the same name was successful in identifying it as a
copy ;-). We already had enough trouble naming the undoable version. We plan
on subclassing:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=39243

> Going past the structural nuances and calling setPropertySourceProvider on
> the UndoablePropertySheetEntry still doesn't work because the EMF
> AdapterFactoryContentProvider expects to be dealing with model objects,

So have your editor send out the model objects as the ISelection instead of
EditParts. Mediate between the EditPartViewer and the selectionservice.

> not with GEF EditParts. In this case I suspect that the EMF provider
> should respect the IAdapter aspect of the EditPart and get the job done.

> This is not a simple "GEF is at fault"/"EMF is at fault" decision. There
> is a problem with the way these packages cooperate within the Eclipse
> framework, and I think that some curious design decisions are making it
> difficult for the less experienced of us to figure out what we are
> supposed to do. I am reminded of a battle I had many years ago with the
> ISPF and GDDM guys within IBM on why those two products just couldn't get
> along. At least we have the source code (for Eclipse) nowadays so that we
> can figure it out.
>
>>>I have decided to see if I can use the EMF generated providers to do the
>>>properties.
>>
>>
>> I would not design my application that way. It's straightforward to
>> write a propertysource implementation yourself. It is nothing but a big
>> switch statement.
>
> I haven't seen any convenient mechanisms to properly handle an EEnum,
> which was the basis for the original question. I can take apart the EMF
> ItemPropertyDescriptor to see how it does it, but why should I be
> essentially copying functionality from an existing set of code? Why can't
> I just use the provider that the EMF generates for me automatically?

Because writing a switch statement is really easy, and you don't encounter
all of the problems you described above, including the mangling of undo/redo
with nested properties or multiple selection.

Re: EMF enum property editor [message #167468 is a reply to message #167391]

Tue, 08 February 2005 13:15

Eclipse User

"Barry Lay" <blay@laysercomputing.com> wrote in message
news:cu9k5o$e9f$1@www.eclipse.org...
> Randy Hudson wrote:
>
> > Displaying an EMF object in the property sheet has nothing to do with
GEF.
>
> Ah, but it does. If you follow the "redbook" example and use
> GEFPlugin.createUndoablePropertySheetEntry(getCommandStack() ) and set
> that as the rootEntry for the property sheet page then things don't work
> according to the PlugIn Guide.
>
> Following the guide and the EMF editor example, setting the
> PropertySourceProvider on the PropertySheetPage to an appropriate
> content adapter should allow the EMF item provider to deliver
> PropertyDescriptors for the Property view. It doesn't work because the
> GEF UndoablePropertySheetEntry extends an internal GEF version of
> PropertySheetEntry which is not recognized by the
> setPropertySourceProvider method in PropertySheetPage. The latter
> silently does nothing which provides a debugging challenge.

The EDiagram example uses the EMF-generated providers for properties. I
spent some time trying to sort out how things would work together (esp. the
undo/redo), so others could do it relatively easily. Look at
EDiagramEditor#getAdapter().

>
> In my opinion it is a poor design choice to advertise that setRootEntry
> on the Eclipse PropertySheetPage takes an IPropertySheetEntry but in
> fact requires a bonafide PropertySheetEntry to function properly. It is
> also a poor design choice on the GEF side to copy and modify the text of
> an existing class (PropertySheetEntry) into an internal package without
> even changing the name. You have to look at the imports to figure out
> why it doesn't work.
>
> Going past the structural nuances and calling setPropertySourceProvider
> on the UndoablePropertySheetEntry still doesn't work because the EMF
> AdapterFactoryContentProvider expects to be dealing with model objects,
> not with GEF EditParts. In this case I suspect that the EMF provider
> should respect the IAdapter aspect of the EditPart and get the job done.
>
> This is not a simple "GEF is at fault"/"EMF is at fault" decision.
> There is a problem with the way these packages cooperate within the
> Eclipse framework, and I think that some curious design decisions are
> making it difficult for the less experienced of us to figure out what we
> are supposed to do. I am reminded of a battle I had many years ago with
> the ISPF and GDDM guys within IBM on why those two products just
> couldn't get along. At least we have the source code (for Eclipse)
> nowadays so that we can figure it out.
>
> >>I have decided to see if I can use the EMF generated providers to do the
> >>properties.
> >
> >
> > I would not design my application that way. It's straightforward to
write a
> > propertysource implementation yourself. It is nothing but a big switch
> > statement.
>
> I haven't seen any convenient mechanisms to properly handle an EEnum,
> which was the basis for the original question. I can take apart the EMF
> ItemPropertyDescriptor to see how it does it, but why should I be
> essentially copying functionality from an existing set of code? Why
> can't I just use the provider that the EMF generates for me automatically?
>
> > There is a redbook on this subject.
>
> The one I have been looking at is "Eclipse Development using the
> Graphical Editing Framework and the Eclipse Modeling Framework",
> SG24-6302. I see your name in the contributions (or someone whose name
> is spelled the same as yours).
>
> I appreciate your help. i have no axe to grind regarding the design of
> any of the products I have been dealing with; I am just trying to get my
> program to work.
>
> Thanks,
> Barry

Re: EMF enum property editor [message #167474 is a reply to message #167468]

Tue, 08 February 2005 18:48

Eclipse User

Pratik Shah wrote:
> The EDiagram example uses the EMF-generated providers for properties. I
> spent some time trying to sort out how things would work together (esp. the
> undo/redo), so others could do it relatively easily. Look at
> EDiagramEditor#getAdapter().

Ok, I am going through it now. Incidentally, I get compile errors for
this project, for things like ShortestPathConnectionRouter not resolved
and cannot invoke abstract method initCellEditor on DirectEditManager.
Is this example based on a newer version of Draw2D and GEF than the
current release? I am running Draw2D and GEF 3.0.1.

Thanks,
Barry

Re: EMF enum property editor [message #167650 is a reply to message #167474]

Wed, 09 February 2005 19:01

Eclipse User

Yes, it's built on the 3.1 code-base. The latter, however, was an actual
problem (I had unreleased changes in my workspace). Synch up with the
repository again. As for the ShortestPathConnectionRouter, you can either
just replace it with some other router in the code, or you'll have to move
to the 3.1 code-base.

"Barry Lay" <blay@laysercomputing.com> wrote in message
news:cubj4l$bo9$1@www.eclipse.org...
> Pratik Shah wrote:
> > The EDiagram example uses the EMF-generated providers for properties. I
> > spent some time trying to sort out how things would work together (esp.
the
> > undo/redo), so others could do it relatively easily. Look at
> > EDiagramEditor#getAdapter().
>
> Ok, I am going through it now. Incidentally, I get compile errors for
> this project, for things like ShortestPathConnectionRouter not resolved
> and cannot invoke abstract method initCellEditor on DirectEditManager.
> Is this example based on a newer version of Draw2D and GEF than the
> current release? I am running Draw2D and GEF 3.0.1.
>
> Thanks,
> Barry

Re: EMF enum property editor [message #167794 is a reply to message #167650]

Thu, 10 February 2005 22:05

Eclipse User

Pratik Shah wrote:
> Yes, it's built on the 3.1 code-base. The latter, however, was an actual
> problem (I had unreleased changes in my workspace). Synch up with the
> repository again.

Now its worse. There appears to be a problem with missing XDoclet
resources.

Thanks again.
Barry

Re: EMF enum property editor [message #167851 is a reply to message #167794]

Fri, 11 February 2005 11:43

Eclipse User

Now when you disabled the ShorestPathRouter or now when you moved to the 3.1
code-base? EMF version should be 3.0.1, and you should have the
org.eclipse.emf.ecore plug-in imported in your workspace.

Can you provide some more information about the error? On what resource
does it occur?

"Barry Lay" <blay@laysercomputing.com> wrote in message
news:cuh7du$sjt$1@www.eclipse.org...
> Pratik Shah wrote:
> > Yes, it's built on the 3.1 code-base. The latter, however, was an
actual
> > problem (I had unreleased changes in my workspace). Synch up with the
> > repository again.
>
> Now its worse. There appears to be a problem with missing XDoclet
> resources.
>
> Thanks again.
> Barry

Re: EMF enum property editor [message #167879 is a reply to message #167851]

Fri, 11 February 2005 13:49

Eclipse User

Pratik Shah wrote:

> Now when you disabled the ShorestPathRouter or now when you moved to the 3.1
> code-base? EMF version should be 3.0.1, and you should have the
> org.eclipse.emf.ecore plug-in imported in your workspace.

It happened when I replaced the project from the repository. I ended up
deleting everything and reloading from CVS. That seems to have fixed
the problem.

Thanks.

Previous Topic:	Drawing error while creating a new Connection
Next Topic:	2 different content panes

Goto Forum:

-=] Back to Top [=-

Current Time: Fri Jun 20 15:10:28 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter