Jump to: navigation, search

Difference between revisions of "Talk:EMF/SinglePageEditor"

m (ISelectionProvider)
(Class definition)
Line 15: Line 15:
 
As you can see the editor extends directly the MultiPageEditorPart and implements the following interfaces:  
 
As you can see the editor extends directly the MultiPageEditorPart and implements the following interfaces:  
  
* IEditingDomainProvider -
+
* IEditingDomainProvider  
 +
* ISelectionProvider
 
* IMenuListener
 
* IMenuListener
 
* IViewerProvider
 
* IViewerProvider
 
* IGotoMarker
 
* IGotoMarker
 
and
 
  
 
=== ISelectionProvider ===
 
=== ISelectionProvider ===
Line 26: Line 25:
 
One idea is to move all the ISelectionProvider relevant methodes into a separate super class and extend the editor class wiht it.
 
One idea is to move all the ISelectionProvider relevant methodes into a separate super class and extend the editor class wiht it.
 
(e.g. [http://code.google.com/a/eclipselabs.org/p/emf/source/browse/org.eclipselabs.emf.addon/src/org/eclipselabs/emf/addon/editor/SelectionProviderEditorPart.java SelectionProviderEditorPart] )
 
(e.g. [http://code.google.com/a/eclipselabs.org/p/emf/source/browse/org.eclipselabs.emf.addon/src/org/eclipselabs/emf/addon/editor/SelectionProviderEditorPart.java SelectionProviderEditorPart] )
 +
 +
=== IEditingDomainProvider  ===
 +
 +
Because each standard EMF editor uses a AdapterFactoryEditingDomain to track the changes in the model IHMO it make sense to define a abstract class some standard definitions.
 +
(e.g. [http://code.google.com/a/eclipselabs.org/p/emf/source/browse/org.eclipselabs.emf.addon/src/org/eclipselabs/emf/addon/editor/AbstractEMFEditorPart.java AbstractEMFEditorPart])

Revision as of 12:54, 3 January 2011

This page shall provide a discussion about the EMF Editor and about some improvements:

Please try to reflect the structure of the main page and please explain the current situation on the main page before starting a discussion about:

Files

Classes

The code generator produces just 4 classes. That is nice in the first place because you get fast a overview on all but if you take a look into the editor class (the first and the second time) it is almost unmanageable.

There is so many stuff included ....

Class definition

As you can see the editor extends directly the MultiPageEditorPart and implements the following interfaces:

  • IEditingDomainProvider
  • ISelectionProvider
  • IMenuListener
  • IViewerProvider
  • IGotoMarker

ISelectionProvider

One idea is to move all the ISelectionProvider relevant methodes into a separate super class and extend the editor class wiht it. (e.g. SelectionProviderEditorPart )

IEditingDomainProvider

Because each standard EMF editor uses a AdapterFactoryEditingDomain to track the changes in the model IHMO it make sense to define a abstract class some standard definitions. (e.g. AbstractEMFEditorPart)