Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Talk:EMF/SinglePageEditor"

(Problem Indicator)
 
(15 intermediate revisions by the same user not shown)
Line 6: Line 6:
 
== Classes  ==
 
== Classes  ==
 
The code generator produces just 4 classes.  
 
The code generator produces just 4 classes.  
That is nice in the first place because you get fast a overview on all  
+
This is nice in the first place because you get a fast overview on all classes but if you take a closer look into the editor class it covers to many aspects just in one class.
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 ....
+
IHMO there is too many stuff included ....
  
 
== Class definition  ==
 
== Class definition  ==
  
As you can see extends the generated file directly the MultiPageEditorPart.
+
As you can see the editor extends directly the MultiPageEditorPart and implements the following interfaces:
Therefor it implements (simple) interfaces like ISelectionProvider.
+
 
 +
* 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 with 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] )
 +
 
 +
=== IEditingDomainProvider  ===
 +
 
 +
Because each standard EMF editor uses a AdapterFactoryEditingDomain to track the changes in the model, IHMO it make sense to define a abstract super class with some further standard definitions.
 +
 
 +
Here some ideas of this (see [http://code.google.com/a/eclipselabs.org/p/emf/source/browse/org.eclipselabs.emf.addon/src/org/eclipselabs/emf/addon/editor/AbstractEMFEditorPart.java AbstractEMFEditorPart] )
 +
 
 +
* the definition of AdapterFactoryEditingDomain and ComposedAdapterFactory
 +
* provide a standard implementation of getAdapter
 +
* add getPropertySheetPage and getContentOutlinePage
 +
* a definition of a generic ContentPropertySheetPage instead to define always an anonym class
 +
* implement the IEditingDomainProvider interface
 +
 
 +
== Problem Indicator  ==
 +
 
 +
The generated ProblemIndicationAdapter class is already more or less independent form the rest of the editor.  
 +
Therefor it is one of the first classes to extract and to generalize.
 +
 
 +
Other methods are related to this topic can be combine in a separate class [http://code.google.com/a/eclipselabs.org/p/emf/source/browse/org.eclipselabs.emf.addon/src/org/eclipselabs/emf/addon/editor/ProblemIndication.java ProblemIndication]
 +
* resourceToDiagnosticMap
 +
* markerHelper
 +
* updateProblemIndication
 +
* updateProblemIndication() (partly)
 +
* analyzeResourceProblems
 +
 
 +
at least for the major parts of it.
 +
 
 +
== Resource Management  ==
 +
 
 +
Next big topic is resources. e.g. for the JFace text editor environment a document provider existes. 
 +
A document is in this context the model part of the MVC and the document provider a special part of the controller.
 +
If the EMF model itself is here the model the editor act as an controller. IMHO the resource management (e.g. save) should bin i a sperate class.
 +
Several parts of this can be generalize ( AbstractResourceManager)

Latest revision as of 12:31, 6 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. This is nice in the first place because you get a fast overview on all classes but if you take a closer look into the editor class it covers to many aspects just in one class.

IHMO there is too 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 with 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 super class with some further standard definitions.

Here some ideas of this (see AbstractEMFEditorPart )

  • the definition of AdapterFactoryEditingDomain and ComposedAdapterFactory
  • provide a standard implementation of getAdapter
  • add getPropertySheetPage and getContentOutlinePage
  • a definition of a generic ContentPropertySheetPage instead to define always an anonym class
  • implement the IEditingDomainProvider interface

Problem Indicator

The generated ProblemIndicationAdapter class is already more or less independent form the rest of the editor. Therefor it is one of the first classes to extract and to generalize.

Other methods are related to this topic can be combine in a separate class ProblemIndication

  • resourceToDiagnosticMap
  • markerHelper
  • updateProblemIndication
  • updateProblemIndication() (partly)
  • analyzeResourceProblems

at least for the major parts of it.

Resource Management

Next big topic is resources. e.g. for the JFace text editor environment a document provider existes. A document is in this context the model part of the MVC and the document provider a special part of the controller. If the EMF model itself is here the model the editor act as an controller. IMHO the resource management (e.g. save) should bin i a sperate class. Several parts of this can be generalize ( AbstractResourceManager)

Back to the top