Improve Message View Editing

Issue #131 resolved
Matthias Schoettle created an issue

This continues issue #66.

Add support for the following:

  • add proper support for create and delete messages
  • add support for combined fragments: Tap-and-hold on the spacer where creation of new messages is allowed and show options for Statement and Combined Fragment.
  • visualize and edit execution statements
  • add support to select or define return of a message
  • allow renaming of the assignTo (if it is "local" to the message view, i.e., it is not a structural feature)

Comments (40)

  1. Matthias Schoettle reporter

    References issue #131: Added support for create and delete messages using constructors and destructors.

    When selecting a lifeline, also all metaclasses that contain constructors are shown. In case a constructor is selected the appropriate reference is created.

    Limitations: - delete message: destruction occurrence not yet created and displayed - create message: currently the name of the assignTo cannot be changed. Also, if the assignTo is changed, the lifeline's represents is not updated.

    → <<cset 0ebd63117d1b>>

  2. Matthias Schoettle reporter

    References issue #131: Destruction occurrence is created and displayed on the spacer after. Also, no messages can be created after a destruction.

    → <<cset 25092227a950>>

  3. Matthias Schoettle reporter

    References issue #131: Added visualization and creation of execution statements.

    Because the statement needs more space then there is space on the lifeline, the lifeline contains a placeholder and the actual view is added to the MessageViewView itself.

    This can then be used for CombinedFragments as well.

    → <<cset 641eeba63286>>

  4. Matthias Schoettle reporter

    References issue #131: Added initial support for combined fragments.

    CombinedFragments and InteractionOperands are added independent of each other, because of their different structure and to allow adding and removing of operands.

    The adaptive layout needs to be a vertical layout and also update the height of the actual view.

    The EventContainer is reused for operands but no line should be displayed.

    → <<cset 74f40c4fe38f>>

  5. Matthias Schoettle reporter

    References issue #131: Continued support for Combined Fragments:

    Maps keep track of which fragment belongs to which EventContainer and which EventContainer represents which FragmentContainer. Therefore, all methods using the previous single event container were updated.

    The fragment to container map is necessary, because when deleting a fragment, it cannot be queried for its container anymore.

    The operand view is now observing the model element and forwards the notification event to the message view view.

    getFragmentBefore cannot obtain the corresponding EventContainer. Therefore pick(...) is used to get the actual component that was tapped, which also reveals the container.

    The layouting was updated such that first all fragments are obtained and then iterated to layout the message view. That way there is no need to consider combined fragments differently. Except, that combined fragments need more spacing, because of additional elements.

    → <<cset 203ee9a09b59>>

  6. Matthias Schoettle reporter

    References issue #131: The top part of the LifelineView is a ContainerComponent and hence also has a tap and hold processor. In that case the LifelineViewHandler also received an event, which caused a ClassCastException.

    → <<cset 90b6e79bb23b>>

  7. Matthias Schoettle reporter

    References issue #131: Improved to LifelineView:

    • actual view of placeholder is not resiszed anymore
    • notifications from operand are only forwarded when the exact lifeline is affected (for fragments)
    • fixed event container usage, where constant 2 was used instead of initial children field
    • when the lifeline gets translated, it now also notifies the parent through the layout system

    → <<cset 35054c0e4e47>>

  8. Matthias Schoettle reporter

    References issue #131: Improved MessageViewView:

    • removed workaround when removing the listener
    • made MessageViewView a RamRectangleComponent in order to be able to receive layout updates from children

    → <<cset 4b033f97e7d1>>

  9. Matthias Schoettle reporter

    References issue #131: Improved layouting of message views:

    • split layout in separate methods
    • made layouting of fragments recursive to support InteractionOperands
    • added proper support for CombinedFragments: The width is determined first, then, during layouting of fragments the y position is determined. After recursively calling the layoutFragments method the height of the CombinedFragment can be determined and set.

    Limitation: Currently, this only supports one operand. Instead of setting the height for the combined fragment, the height of the operands needs to be set.

    → <<cset 51335110f8d6>>

  10. Matthias Schoettle reporter

    References issue #131: Reverted changes from commit f1cce22: In case the lifeline starts with create always 2 need to be subtracted from the view index, because 2 additional components on the lifeline are missing.

    → <<cset 590d90e00107>>

  11. Matthias Schoettle reporter

    References issue #131: Fixed bug, where layout will always be created for a new message view. This caused a NPE when a message view + message was created, both undone and redone.

    Because the message view was added first, the layout created through a command was never available. Now the layout command is executed first.

    → <<cset a7e23b6ff327>>

  12. Matthias Schoettle reporter

    References issue #131: Added notifications for InteractionFragment#covered in order for a CombinedFragment to react to changes to it.

    → <<cset 84bdd76ebc37>>

  13. Matthias Schoettle reporter

    References issue #131: Fixes:

    • when a new message and lifeline is created inside an operand, the combined fragment will also cover the new lifeline
    • relayouting of the message view when deleting a message is only done once the message ends are deleted (happens last)

    → <<cset 000c1c738c6c>>

  14. Matthias Schoettle reporter

    References issue #131: Improved CombinedFragment support:

    The CombinedFragmentView doesn't need to be resized. Instead, each operand is. This allows to properly size the operands when layouting and to consider the operand header (constraint) height.

    → <<cset 4627c5380183>>

  15. Matthias Schoettle reporter

    References issue #131: Improved support for CombinedFragments:

    • added handlers for operator and constraints
    • temporarily always 2 operands are created until additional ones can be created manually

    → <<cset 6a5693bf5ba6>>

  16. Matthias Schoettle reporter

    References issue #131: Made item providers more fail safe against unset (null) references. Especially necessary when using the generated editor.

    → <<cset e042a3df036b>>

  17. Matthias Schoettle reporter

    References issue #131: Improvements to item providers:

    • Lifeline#represents: Actual receive event (not from reply or self message) is searched for
    • Message#signature: send event of reply message needs to considered as well for callReceiver (to be able to set it in the generated editor)
    • fixed naming of gates (was reversed)
    • improved collecting valid call receivers: both mapping directions, all extended aspects and classifiers with the same name (from the same or an extended aspect) are considered

    → <<cset ec1d339a4250>>

  18. Matthias Schoettle reporter

    References issue #131: Bug fixes:

    • disabled debugging colours
    • changed line stipple of operand container to dashed, which will result in a dashed separator line (the rest of the border is not seen, because the combined fragment view border is on top)

    → <<cset 3f93b6e31b7b>>

  19. Matthias Schoettle reporter

    References issue #131: Fixed problem when finding the proper index to add the message ends (reply messages were not considered properly).

    → <<cset cd3ab0b8e483>>

  20. Matthias Schoettle reporter

    References issue #131: Improved support for assignments:

    • An existing temporary property can be renamed.
    • If a new value is selected and a temporary property was already used, the existing one is deleted.
    • For create messages, the new assignment value is also set as the lifeline represents.
    • When deleting messages, also temporary properties used in assignments of the deleted messages are deleted.

    → <<cset 3894c540e800>>

  21. Matthias Schoettle reporter

    References issue #131: Support for value specification (for actual parameters of message calls and returns of messages):

    • MessageCallView now displays the return text view of reply messages and allows to specify the return through a handler.
    • ValueSpecificationHandler can handle any containing value specification (ParameterValueMapping.value and Message.returns): The selector displays available choices and allows to create literal specifications. The values of literal specifications can be changed through an extra button. The complete ValueSpecification can also be replaced with a different one, leading to the existing one being deleted.
    • InteractionConstraintHandler can handle interaction constraints: On first event handling, the proper value specification and its feature are determined and set for the text view.

    → <<cset 462c569b5c94>>

  22. Matthias Schoettle reporter
    • edited description

    reordering of messages: Allow to drag a message to move it somewhere else moved to issue #165.

  23. Matthias Schoettle reporter

    Resolved issue #192: Revert change from commit 000c1c7 (refs #131): Always decrease the view index by 2 if the lifeline starts with a create message. Otherwise wrong behaviour is observed whenever additional messages are added between existing messages (then the view index will not exceed the child count). Also, when the behaviour of a create message (constructor) is defined and the user tries to create the first message in the behaviour, this won't happen (since there is a reply message).

    → <<cset a0afe24af810>>

  24. Matthias Schoettle reporter

    References issue #131: Improved getting the view index for a fragment. First, existing fragment views are checked whether they represent the given fragment. If none is found, the fallback is to use the number of fragments before (the fragment will not exist on the lifeline yet).

    This is necessary, because when removing messages, during layouting of fragments, the given model index might lead to a wrong view index (because the events weren't removed yet from the model), resulting in returning a view that represents another fragment.

    → <<cset 409824d16a01>>

  25. Matthias Schoettle reporter

    References issue #131: Fixed retrieval of getting the index after a given fragment. In certain cases the index would be too high leading to the new fragment being placed at the wrong position.

    → <<cset af9e018f661b>>

  26. Matthias Schoettle reporter

    References issue #131: Further improved the retrieval of the index after a given fragment. In cases where messages have no reply, it is possible that the message or fragment after is not part of the same behaviour (when dealing with nested behaviour). To be able to distinguish it is necessary to keep track of the lifelines that are part of the same behaviour. And, as soon as another lifeline is covered, the end of that behaviour is reached.

    → <<cset 6dcfe3a395f6>>

  27. Matthias Schoettle reporter

    References issue #131: Fixed bounds problem. The for loop started the index off-by-one, so in some cases (e.g., when deleting multiple messages at once) the fragment view could not be found.

    → <<cset ad08501fafa3>>

  28. Matthias Schoettle reporter

    References #131: Fixes the placement of the destruction occurrence lines. The lines are now added only to the receiving end's spacer and on the spacer after that event.

    → <<cset 0bbbc49983ad>>

  29. Log in to comment