Difference between revisions of "Element Hierarchy Extension Point & Library"

From Event-B
Jump to navigationJump to search
imported>Tommy
m
imported>Tommy
m
Line 7: Line 7:
 
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).<br>
 
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).<br>
 
There is no need for such an indirection.
 
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 - Behaviour while loading a file (including a file with invalid parent-child relations occurrences)
 +
E- What about the compatibilty with the file upgrade mechanism?
 +
----
 +
 +
= Some identified difficulties =
 +
 +
== Initialization of elements from non UI components ==
 +
 +
The following ElementDescRegistry method, shows the dependency between an element creation and the initialization of its attributes with default values.
 +
 +
        public <T extends IInternalElement> T createElement(
 +
final IInternalElement root, IInternalElement parent,
 +
final IInternalElementType<T> type, final IInternalElement sibling)
 +
throws RodinDBException {
 +
final T newElement = parent.createChild(type, sibling, null);
 +
final IAttributeDesc[] attrDesc = getAttributes(type);
 +
for (IAttributeDesc desc : attrDesc) {
 +
desc.getManipulation().setDefaultValue(newElement, null);    // <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
 +
}
 +
return newElement;
 +
}
 +
 +
The protocol shall be changed to take into account this initialization outside from the graphical manipulation.
 +
Doing the initialization at org.eventb.core level is possible by registering a special "attribute initializer". <br>
 +
WARNING : The required attribute is only available for "choice" attributes. Can't it be available for all kind of attributes?
 +
 +
== Correspondence between UI manipulation and "core" elements ==
 +
What if an element is not defined in the UI but defined in the hierarchy of a given core element?<br>
 +
>>> ANSWER : it seems that any contributor to the UI manages the extensions of the datat model. The responsability is thus left to him.<br>
 +
>>> A element for which there is no UI correspondance will not be displayed.
 +
 +
== Operation on elements shall be enforced ==
 +
 +
        private <T extends IInternalElement> OperationCreateElement getCreateElement(
 +
IInternalElement parent, IInternalElementType<T> type,
 +
IInternalElement sibling, IAttributeValue[] values) {
 +
OperationCreateElement op = new OperationCreateElement(
 +
createDefaultElement(parent, type, sibling));
 +
op.addSubCommande(new ChangeAttribute(values));
 +
return op;
 +
}
 +
 +
''The Operation model similar to a kind of transaction mechanism, should be made available from the DB layer.''<br>
 +
''The relations when using such layer shall be enforced and any invalid operation could be rejected.''
  
 
= Proposal =
 
= Proposal =
Line 65: Line 115:
  
 
*The part concerning how to display elements and UI related info will stay in the editorItems extension point and shall point to an element definitions and hierachy. Relationships will disappear from the editorItems extension point.
 
*The part concerning how to display elements and UI related info will stay in the editorItems extension point and shall point to an element definitions and hierachy. Relationships will disappear from the editorItems extension point.
 
= Some identified difficulties =
 
 
== Initialization of elements from non UI components ==
 
 
The following ElementDescRegistry method, shows the dependency between an element creation and the initialization of its attributes with default values.
 
 
        public <T extends IInternalElement> T createElement(
 
final IInternalElement root, IInternalElement parent,
 
final IInternalElementType<T> type, final IInternalElement sibling)
 
throws RodinDBException {
 
final T newElement = parent.createChild(type, sibling, null);
 
final IAttributeDesc[] attrDesc = getAttributes(type);
 
for (IAttributeDesc desc : attrDesc) {
 
desc.getManipulation().setDefaultValue(newElement, null);    // <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
 
}
 
return newElement;
 
}
 
 
The protocol shall be changed to take into account this initialization outside from the graphical manipulation.
 
Doing the initialization at org.eventb.core level is possible by registering a special "attribute initializer". <br>
 
WARNING : The required attribute is only available for "choice" attributes. Can't it be available for all kind of attributes?
 
 
== Correspondence between UI manipulation and "core" elements ==
 
What if an element is not defined in the UI but defined in the hierarchy of a given core element?<br>
 
>>> ANSWER : it seems that any contributor to the UI manages the extensions of the datat model. The responsability is thus left to him.<br>
 
>>> A element for which there is no UI correspondance will not be displayed.
 
 
== Operation on elements shall be enforced ==
 
 
        private <T extends IInternalElement> OperationCreateElement getCreateElement(
 
IInternalElement parent, IInternalElementType<T> type,
 
IInternalElement sibling, IAttributeValue[] values) {
 
OperationCreateElement op = new OperationCreateElement(
 
createDefaultElement(parent, type, sibling));
 
op.addSubCommande(new ChangeAttribute(values));
 
return op;
 
}
 
 
''The Operation model similar to a kind of transaction mechanism, should be made available from the DB layer.''<br>
 
''The relations when using such layer shall be enforced and any invalid operation could be rejected.''
 
 
----
 
 
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 - Behaviour while loading a file (including a file with invalid parent-child relations occurrences)
 
E- What about the compatibilty with the file upgrade mechanism?
 
  
 
[[Category:Design_proposal]]
 
[[Category:Design_proposal]]

Revision as of 14:45, 25 September 2012

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 - Behaviour while loading a file (including a file with invalid parent-child relations occurrences)
E- What about the compatibilty with the file upgrade mechanism?

Some identified difficulties

Initialization of elements from non UI components

The following ElementDescRegistry method, shows the dependency between an element creation and the initialization of its attributes with default values.

       public <T extends IInternalElement> T createElement(
			final IInternalElement root, IInternalElement parent,
			final IInternalElementType<T> type, final IInternalElement sibling)
			throws RodinDBException {
		final T newElement = parent.createChild(type, sibling, null);
		final IAttributeDesc[] attrDesc = getAttributes(type);
		for (IAttributeDesc desc : attrDesc) {
			desc.getManipulation().setDefaultValue(newElement, null);    // <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
		}
		return newElement;
	}

The protocol shall be changed to take into account this initialization outside from the graphical manipulation. Doing the initialization at org.eventb.core level is possible by registering a special "attribute initializer".
WARNING : The required attribute is only available for "choice" attributes. Can't it be available for all kind of attributes?

Correspondence between UI manipulation and "core" elements

What if an element is not defined in the UI but defined in the hierarchy of a given core element?
>>> ANSWER : it seems that any contributor to the UI manages the extensions of the datat model. The responsability is thus left to him.
>>> A element for which there is no UI correspondance will not be displayed.

Operation on elements shall be enforced

       private <T extends IInternalElement> OperationCreateElement getCreateElement(
			IInternalElement parent, IInternalElementType<T> type, 
			IInternalElement sibling, IAttributeValue[] values) {
		OperationCreateElement op = new OperationCreateElement( 
				createDefaultElement(parent, type, sibling));
		op.addSubCommande(new ChangeAttribute(values));
		return op;
	}

The Operation model similar to a kind of transaction mechanism, should be made available from the DB layer.
The relations when using such layer shall be enforced and any invalid operation could be rejected.

Proposal

Hierarchy between elements

The part concerning element definition and hierarchy will go to a dedicated extension point in the database.
Here is the definition of such an extension point : org.rodinp.core.dataModel ??? or org.rodinp.core.internalElementHierarchy ???

Configuration Markup:
<!ELEMENT extension ((childRelation | attributeRelation | autoNaming)+)>
<!ATTLIST extension
point CDATA #REQUIRED
id    CDATA #IMPLIED
name  CDATA #IMPLIED
>

<!ELEMENT elementRelationship (childType)+>
<!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
implicitChildProvider CDATA #IMPLIED
>
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 attributeRelationship (attributeType)+>
<!ATTLIST attributeRelationship
elementTypeId CDATA #REQUIRED
>
elementTypeId - Element type of the element, 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
class  CDATA #REQUIRED
>
Describes how to graphically display a Rodin attribute of type boolean.

attributeTypeId - Id of the Rodin attribute type to which this description applies (see extension point org.rodinp.core.attributeTypes).

<!ELEMENT autoNaming EMPTY>
<!ATTLIST autoNaming
elementTypeId          CDATA #REQUIRED
attributeDescriptionId CDATA #REQUIRED
namePrefix             CDATA #REQUIRED
>
Describes how to automatically name an element. The autoNaming definition is unique for a given element type.

elementTypeId - Element type of the element, must be the unique ID of a Rodin internal element type (see extension point org.rodinp.core.internalElementTypes).
namePrefix - default prefix to name the element

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.

  • The part concerning how to display elements and UI related info will stay in the editorItems extension point and shall point to an element definitions and hierachy. Relationships will disappear from the editorItems extension point.