Element Hierarchy Extension Point & Library
The UI in Rodin 2.x contains an extension point org.eventb.ui.editorItems that groups the both following information:
- the definition of elements and attributes and their hierarchy, and the way they are created
- the information needed to correctly display and edit these elements in the various editors and UI components
It appears obvious that the first information should be defined from an extension that belongs to the Database.
To fullfil the above statement, the current extension point org.eventb.ui.editorItems should be split in two.
The existing extension point was also heterogenous. Indeed, whereas the element relationships were concerning element types, the attribute relationship were concerning element types and references to UI defined attributes (referring to core attributes).
There is no need for such an indirection.
The proposal should concern :
A - Relationship declaration (new extension point) B - API to test these relations and traverse them C - Enforcement of the authorized relations when modifying the DB D- What about the compatibilty with the file upgrade mechanism?
Some identified difficulties
Correspondence between UI manipulation and "core" elements
If some element or attribute relationship is declared at the database level, but there is no corresponding
for it, it will be ignored by the UI. This is similar to the previous situation where some elements or attributes could be present in the database but not in the user interface hierarchy.
The part concerning element definition and hierarchy will go to a dedicated extension point in the database.
A - hierarchy definition
Here is the definition of the new extension point : org.rodinp.core.itemRelations which describes the possible children and attributes of internal elements.
Configuration Markup: <!ELEMENT extension (relationship+)> <!ATTLIST extension point CDATA #REQUIRED id CDATA #IMPLIED name CDATA #IMPLIED > <!ELEMENT relationship ((childType | attributeType)+)> <!ATTLIST elementRelationship parentTypeId CDATA #REQUIRED > parentTypeId - Element type of the parent, must be the unique ID of a Rodin internal element type (see extension point org.rodinp.core.internalElementTypes). <!ELEMENT childType EMPTY> <!ATTLIST childType typeId CDATA #REQUIRED > typeId - Element type of the child, must be the unique ID of a Rodin internal element type (see extension point org.rodinp.core.internalElementTypes). <!ELEMENT attributeType EMPTY> <!ATTLIST attributeType typeId CDATA #REQUIRED > attributeTypeId - Id of the Rodin attribute type to which this description applies (see extension point org.rodinp.core.attributeTypes).
The use of such extension point is obvious in org.eventb.core plug-in, as it would complement the extensions of org.rodinp.core.attributeTypes and org.rodinp.core.internalElementTypes.
B - API to declare and test the element/attribute relations and traverse them
The API of the Rodin database is extended as follows:
- interface IInternalElementType is extended with methods
IInternalElementType<?> getParentTypes(); IInternalElementType<?> getChildTypes(); IAttributeType getAttributeTypes();
boolean canParent(IInternalElementType<?> childType); boolean canCarry(IAttributeType attrType);
- interface IAttributeType is extended with methods
boolean isAttributeOf(IInternalElementType<?> elementType);
This list might be later extended with new methods such as
if this proves useful.
D - Compatibility with the upgrade mechanism
Things start with the org.rodinp.core.conversion extension point.
The modifications are done in XPATH there is no incompatibility introduced here.
The part concerning how to display elements and UI related info will stay in the editorItems extension point and shall point to an element definition and hierachy.
Relationships will disappear from the editorItems extension point.