Results of Hacker Day 2018-08 #97
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Priority "normal" or "5" (Integer equivalent) is needed to trump the Ecore visualiser developed by Hallvard Trætteberg et al at https://github.com/hallvard/plantuml.
…lection without calculating the actual diagram text. This change is introduced to conform to the PlantUML API. It may as well reduce computation time, although negligible. However, it is important for understanding and maintaining the code to have these methods implemented as intended. Both methods clearly describe which editors (or in this case their input) and which selections are supported. supportsEditor(...) checks for proper file extensions of the file currently edited, e.g. "ecore", and as well whether or not the editor internally handles EObjects via its EditingDomain. supportsSelection(...) checks the selection for elements that cannot be displayed. If there are any, the selection will be reported as not supported. Utility methods have been added with VisualiserUtilities. The intention of this class is to provide most of the behavior which interacts with the Eclipse Platform API, to keep the Visualiser code as clean as possible. This should in turn improve the maintainability of the Visualiser code.
This is done to improve maintainability. Common behavior is moved to a common super class EMoflonEcoreVisualiser, whereas metamodel or model specific code is moved to the according subclass EMoflonMetamodelVisualiser and EMoflonModelVisualiser. Additional, more precise code for PlantUML API interaction has been added, to determine as precise as possible, whether a given selection is handled by the metamodel or model visualiser, or not at all. Ecore visualisers now should act as intended by the PlantUML API. Also removes code to handle correspondence model. Firstly, this functionality does not belong with functionality to visualise Ecore metamodels or models. Secondly, the improved checking methods for supported editors and selections allow for a more appropriate visualiser to handle correspondence models.
… and model visualisers. Since supportsEditor(...) and supportsSelection(...) already required functionality to extract selections from IEditorPart and ISelection instances, it was no longer required to keep this code in the respective implementations for metamodel and model visualisers. Likewise for the expansion of Resource elements. The functionality is given in VisualiserUtilities since commit 9175f43.
…me diagram. Reason for this bug is, that even if a selection is reported to be not supported (in contrast to the editor), PlantUML will call getDiagramText(...) with a null selection. Semi-correctly, it was assumed that the editor output can be used to generate the diagram text. However, it was not checked wether or not the editor output can be clearly classified to contain only metamodel or model elements. After adding this check and performing some extra improvements on the EMoflonEcoreVisualiser code the bug had been fixed.
Metamodel and model visualiser both contained chained methods, which were simply flattened to achieve a better readable source code.
…Operations, EParameters, EGenericTypes or EStructuralFeatures. Previously, if one of the above element types has been selected in the metamodel visualiser, instead of its containing class element, the EObject itself was visualised by the model visualiser or not at all, if it was contained in a selection consisting of EObjects and EModelElements / EGenericTypes. This was the case because no representation for these elements were chosen, only EClasses in a selection could be visualised by the metamodel visualiser. Now, EStructuralFeatures, EOperations and EParameters are represented by their according containing EClasses. EPackages are represented by their contained EClassifiers and those contained in their subpackages. An EGernericType is represented by its EClassifier. One problem still remains, EDataTypes (a specialization of EClassifier) cannot be represented by an EClass. Which means, they cannot be visualised, if selected (an empty PlantUML diagram will be returned).
…liser. Common behavior, i.e. #handleOpposites(...) is moved to Ecore visualiser and can therefore be used by both concrete visualisers. The PlantUMLGenerator has been adjusted accordingly. This commit is a preparation for a larger refactoring, in which the control over which elements are visualised is isolated from the PlantUML generator.
Before this commit, the PlantUML generator had partial control over which elements to visualise and which not. For example, the superclass of an EClass was always visualised, including the generalisation dependency. This behavior may change in the future, amongst other. The new agenda for the PlantUML generator is to preciselly draw what is given to it. All calculations for determining superclasses have been added to the metamodel visualiser and removed from the generator. The generalisation dependency is now given in the form of a VisualEdge. To differentiate between the different kinds of edges, an Enum has been added, which for now differentiates between LINK (model), REFERENCE (metamodel) and GENERALISATION (metamodel). Accordingly, the generation of edges in the PlantUML generator has been unified into one method.
…amodel and model visualisers. This refactoring includes various strategies for the computation of object and class diagrams by the model and meta model visualiser. To simplify the chaining of multiple strategies for diagram manipulation, new container types are introduced: Diagram, ClassDiagram and ObjectDiagram. Amongst others, they store the selection and neighbourhood of nodes, as well as the edges between them. The PlantUML generator was adjusted to draw ClassDiagrams and ObjectDiagrams. Hence, future functional enhancements might benefit from these new container classes. The new container types are important for strategy operations, since chaining of strategies is more easily possible. Initial strategies include: edge creation for a selection of nodes and bidirectional expansion of the current neighbourhood by a degree of one. If a higher degree is wished, the latter method can simply be chained. The mentioned strategies have been added for object and class diagrams. In proceeding of the refactoring, all List type-references have been changed to the more general Collection, whereas internally HashMaps are used if a collection type is to be instantiated. This should improve the performance, as the order of elements appears to be not of relevance.
If an eMoflon visualiser implements the ConfigurableVisualiser interface, it can be configured by the singleton Configurator class. E.g. handlers can then instruct the configurator to set a diagram processing strategy or style bits for the PlantUML code generation. Everything method that conforms to the functional interface DiagramStrategy may be passed to the configurator as a strategy. A DiagramStrategy takes a diagram as input, and returns the processed diagram. The actual type, or what passes as a diagram, is not enforced. However, the ConfigurableVisualiser interface defines a generic type paramater to associate a configurable visualiser with a diagram type and hence, the diagram type supported by a strategy for that visualiser. For example, the metamodel visualiser uses ClassDiagram as container type for a class diagram. Therefore it will only accept methods as strategy which take a ClassDiagram instance as input and return value. The EMoflonPlantUMLGenerator has been adjusted to take style bits as an input for its metamodel and model generation methods. However, no functionality has been implemented with it, as this will follow in later commits.
This toggle button allows to switch between additional details for models or none. Internally, a style bit in combination with the Configurator class has been used. The style bits are handed to the PlantUMLGenerator, where they are evaluated. In addition, the PlantUMLGenerator has been extended to generate operations and attributes of EClass elements as well.
…models. For this addition, a new command, handler and menu contribution has been added to plugin.xml. The according handler class sets a style bit in the Configurator instance. This stylebit is handed to the EMoflonPlantUMLGenerator via the configurable metamodel and model visualisers. Internally the generator uses apache StringUtils to crop the middle of an oversized string. By default, a string counts as oversized if its length exceeds 11 characters. This length bound is not configurable, however, a realization using the preference store should be feasible. In addition, the notation in model visualisations has been adjusted. Objects are now named <instance_name> : <class_name> instead of <instance_name>.<class_name>.
…sualiser. If the action is active, the associated handler sets the a the according bidirectional 1-neighbourhood strategy via the configurator. The metamodel and model visualisers will execute this strategy, and the 1-neighbourhood for the current selection will be added to the diagram. So far, this is only supported with the model and metamodel visualisers. This commit does not include an enableWhen clause for the handler. If one wishes to add an own handler, to enable the support for other visualisers as well, this has to be done, e.g. via a property tester, which calls supportsEditor and supportsSelection on the visualisers. Only one handler can be active for a command at the same time, which is why the included handler cannot be active in this case.
The metamodel visualiser was extended to support the extraction of documentation values from EAnnotations. A handler for a ViewAction has been added, to toggle the visualisation of these documentation values in the PlantUML view. To toggle this, the Handler instructs the Configurator to set a specific style bit. In addition, a bug in the VisualiserUtilities has been fixed. Previously, EMap Entries where contained in an expanded Resource / ResourceSet, which couldn't be handled by the metamodel visualiser. This is has been fixed by removing these elements from the result.
…or objects in models. The calculation for object naming is now performed in the model visualiser itself, the result is stored in the ObjectDiagram. This is handed to the generator. The names are named like this <family1 : Family> instead of <o1 : Family>. Object instance names are still not ordered according to their containment relation, this is future work. Instead, the numbers trailing the Object instance names are unique, but randomly assigned to the object. The colors for both metamodel and model have been adjusted to be black and white, with the exception of EPackage representations in metamodels. They are colored in a light gray.
… both .xmi and .ecore Resources are selected. The problem: If both .xmi and .ecore Resources were selected in a supported editor, either the EcoreVisualiser correctly reported an error diagram or the plantuml.ecore plugin visualised one of the resources. The cause: Both PlantUML ecore visualisers and both the emMoflon metamodel and model visualiser had the same "default" priority. Dependending on the order, in which eMoflon and PlantUML ecore visualiser were loaded by the PlantUML.eclipse plugin, either one of those was asked first to visualise. The order in which the PlantUML.eclipse Activator loads the visualisers appears to be undeterministic. Furthermore, the supportsSelection check of the PlatnUML.ecore visualiser checks only the first element of a selection. Which again is influenced by which Resource is selected first in the Editor. The process of choosing a visualiser for getting the diagram text is devided into two phases: first supportsEditor and supportsSelection is called. If supportsEditor returns true, but not supportsSelection, the second phase starts. There again supportsEditor and supportsSelection are called, the latter with a null argument for the selection. Both PlantUML.ecore and eModflon visualisers seem to return the same result in this case, i.e. true, such that the first visualiser in line is chosen for diagram text generation. The fix: The priority value of the eMoflon metamodel and model visualisers has been increased to "custom" (=10), in contrast to "default" (=5). This way the eMoflon metamodel and model visualisers always chosen first for diagram text generation. Thus, the behavior is deterministic.
Closes Avoid NPE in eMoflonUtils getSymbolicName #341
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Solved issues:
Add link to tutorial Replace tutorial for hints on how to install an update site #92
Make multi-status aware error reporter more robust Make multi-status aware error reporter more robust #95
Avoid implementations of BiMap and BiHashMap Avoid implementations of BiMap and BiHashMap #84
Add menu entry to register EMF metamodel Add menu entry to register EMF metamodel #89
Migrate useful extensions from TIE::GT to Core.
Merge other PRs