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

From Event-B
Jump to navigationJump to search
imported>Laurent
imported>Laurent
 
(9 intermediate revisions by 2 users not shown)
Line 13: Line 13:
 
  B - API to test these relations and traverse them
 
  B - API to test these relations and traverse them
 
  C - Enforcement of the authorized relations when modifying the DB
 
  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)
+
  D- What about the compatibilty with the file upgrade mechanism?
E- What about the compatibilty with the file upgrade mechanism?
 
 
----
 
----
  
 
= Some identified difficulties =
 
= 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 : Only "choice" attributes can be marked as mandatory ({{ident|required}} attribute of the extension). Can't it be available for all kind of attributes?
 
  
 
== Correspondence between UI manipulation and "core" elements ==
 
== Correspondence between UI manipulation and "core" elements ==
 
If some element or attribute relationship is declared at the database level, but there is no corresponding {{ident|editorItem}} 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.
 
If some element or attribute relationship is declared at the database level, but there is no corresponding {{ident|editorItem}} 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.
  
== 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 =
 
== Hierarchy between elements ==
 
  
 
The part concerning element definition and hierarchy will go to a dedicated extension point in the database.
 
The part concerning element definition and hierarchy will go to a dedicated extension point in the database.
Line 64: Line 29:
 
=== A - hierarchy definition ===
 
=== A - hierarchy definition ===
  
Here is the definition of such an extension point : org.rodinp.core.dataModel ???  or org.rodinp.core.internalElementHierarchy ???
+
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:
 
  Configuration Markup:
Line 96: Line 61:
 
=== B - API to declare and test the element/attribute relations and traverse them ===
 
=== B - API to declare and test the element/attribute relations and traverse them ===
  
The API for an element : IElementDesc
+
The API of the Rodin database is extended as follows:
 
 
public String getID();
 
 
public List<IAttributeRelationship> getAttributeRelationships();
 
 
public List<IElementRelationship> getChildRelationships();
 
 
 
        public List<IAttributeType> getAttributeTypes();
 
 
public List<IElementType> getChildTypes();
 
 
public IAttributeDesc getAutoNameAttribute();
 
 
 
adding the following method to the protocol :
 
  
        public boolean isDirectChildTypeOf(IElementDesc parentElemDesc);
+
* interface IInternalElementType is extended with methods
  
        public boolean isOwnableAttribute(IAttributeDesc ownerElementDesc);
+
  IInternalElementType<?>[] getParentTypes();
 +
  IInternalElementType<?>[] getChildTypes();
 +
  IAttributeType[] getAttributeTypes();
  
with the same interface IElementRelationship
+
  boolean canParent(IInternalElementType<?> childType);
 +
  boolean canCarry(IAttributeType attrType);
  
public interface IElementRelationship extends Comparable<IElementRelationship> {
+
* interface IAttributeType is extended with methods
 
public String getID();
 
 
public IElementType<?> getParentType();
 
 
public IInternalElementType<?> getChildType();
 
 
public IImplicitChildProvider getImplicitChildProvider();
 
 
public int getPriority();
 
 
}
 
  
with the "new" interface IAttributeRelationship
+
  IInternalElementType<?>[] getElementTypes();
  
public interface IAttributeRelationship extends Comparable<IAttributeRelationship> {
+
  boolean isAttributeOf(IInternalElementType<?> elementType);
 
public String getID();
 
 
public IElementType<?> getOwnerType();
 
 
public int getPriority();
 
 
}
 
 
 
''IImplicitChildProvider is moved to Event-b Core.''
 
 
 
The API for an Attribute : IAttributeDesc
 
 
        public String getID(); 
 
     
 
        public IAttributeManipulation getManipulation();
 
 
public IAttributeType getAttributeType();
 
  
=== C - Data model operations (enforced) ===
+
This list might be later extended with new methods such as
The ElementManipulationFacade, support for modifications over the Database, should be provided by the Event-B Core plug-in.<br>
+
{{ident|isAncestorOf}} if this proves useful.
The IAttributeManipulation interface should be also provided by the Event-B Core plug-in as it concerns the manipulation done on the attribute in the DB.
 
  
The information about the rendering of an element or an attribute, should not be deduced from the attribute itself (e.g. choiceAttribute vs. toggleAttribute vs. textAttribute), it should be given in the UI.
+
=== D - Compatibility with the upgrade mechanism ===
  
It seems that the ElementManipulationFacade can be used as protocol, but hiercharchy between elements and elements, or between elements and attributes shall be enforced.
+
Things start with the org.rodinp.core.conversion extension point.<br>
''Proposition : add Exceptions to methods of the protocol.''
+
The modifications are done in XPATH  there is no incompatibility introduced here.  
  
 
== UI related information ==
 
== UI related information ==
Line 167: Line 90:
 
Relationships will disappear from the editorItems extension point.
 
Relationships will disappear from the editorItems extension point.
  
The interfaces are refactored to become the following :
 
 
''NB. IITemDesc disappears as it is cumbersome to provide such interface for a sole method getPrefix(). ''
 
 
public interface IUIElementDesc extends IItemDesc {
 
 
        public String getPrefix();
 
 
public String getChildrenSuffix();
 
 
public IImageProvider getImageProvider();
 
 
public IAttributeDesc atColumn(int i);
 
 
public int getDefaultColumn();
 
 
public boolean isSelectable(int i);
 
 
public String getAutoNamePrefix();
 
 
public IElementPrettyPrinter getPrettyPrinter();
 
 
}
 
 
public interface IUIAttributeDesc extends IItemDesc {
 
 
        public String getPrefix();
 
 
public String getSuffix();
 
 
public IEditComposite createWidget();
 
 
public boolean isHorizontalExpand();
 
 
}
 
 
=== D - Behaviour while loading a file ===
 
This is including a file with invalid parent-child relations occurrences.
 
 
The elements or attributes shall be let in place, and not be displayed.
 
 
The test wether a child as an incorrect parent shall be provided, <br>
 
or if a parent is valid for a given child :<br>
 
HOW?
 
 
> One possibility : checking the relationship from the element desc:
 
 
ElementDescRegistry.getElementDesc(element).isValidChildOf(IInternalElement parent);
 
 
ElementDescRegistry.getElementDesc(element).isValidParentOf(IInternalElement child);
 
 
=== E - Compatibility with the upgrade mechanism ===
 
 
Things start with the org.rodinp.core.conversion extensions point.<br>
 
The hierarchy (element/element and element/attributes) is implicit in the extensions,
 
but does not appear in code.
 
  
 
[[Category:Design_proposal]]
 
[[Category:Design_proposal]]

Latest revision as of 13:17, 12 October 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- 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

editorItem

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.


Proposal

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
 IInternalElementType<?>[] getElementTypes();
 boolean isAttributeOf(IInternalElementType<?> elementType);

This list might be later extended with new methods such as

isAncestorOf

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.

UI related information

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.