Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Copy/Paste] Relation not copied if nested objects copied and pasted #26

Closed
Phillipus opened this issue Feb 17, 2014 · 6 comments
Closed
Labels

Comments

@Phillipus
Copy link
Member

When copy/pasting nested elements, the relation that exists between parent and child is not kept. This is because there's no relation object shown on the diagram.

  1. Create a Business Actor on a View.
  2. Create Business Role on same View directly inside of Business Actor, creating an Assignment Relationship.
  3. Select Business Actor and Copy & Paste

No relationship copy is made.

However, if you now drag the Business Role out of its parent (Business Actor) and drag it back in again and repeat the steps a relationship copy is made.

Copy & Paste logic is looking for actual DiagramModelConnection, not implicit.

Bugger.

@Phillipus
Copy link
Member Author

This is really a symptom of how nested connections have been implemented.

If a new child object is added to a parent object from drag and drop then a new diagram connection is made based on the newly created model relationship.

If you put an existing child inside a parent object that has a model relationship, a new diagram connection is not made based on that model relationship.

The workaround is to drag the child out of the parent and drag it back in again.

When a diagram object is nested, the real connection is hidden using NestedConnectionEditPartFilter.

This should really be re-written so that nesting an object actually removes the diagram connection. Then change the logic so that an implicit connection exists based on existing element relationship and nesting.

@Phillipus
Copy link
Member Author

Look at:

NestedConnectionEditPartFilter
CreateDiagramArchimateObjectCommand
ArchimateContainerLayoutPolicy
DiagramCommandFactory.createNewNestedRelationCommandWithDialog()
ArchimateDNDEditPolicy

@Phillipus
Copy link
Member Author

If we go the way of Issue #28 then in CopyPasteSnapshot create new Relationships in the copied elements based on nesting rather than existing Diagram connections.

@mbd-dbc-dk
Copy link
Contributor

I am not sure this is related, but I looked at the code in CopySnapshot.getConnectionsToCopy(), and as it is now, the user have no way of controlling what connections between any two elements are copied: if the elements are present in the diagram, they will be copied, even if the user did not actually select them... (i tested this, its either very convenient, or quite confusing, depending on your point of view).

I am clearly new to the codebase, but it seems to me, some of these issues is because of the code that sets up the CopySnapshot, in CopyAction.run. Here, only IDiagramModelObjects are copied, not the connections? (I checked, and as far as I can tell, the connections are part of the selection, at least in my simple test). Afterwards in CopySnapshot, the toplevel objects are identified, and the code (seems to) rebuilds the treelike structure of the diagrammodel that is in the selection, but totally ignores the connections...

It would seem to me, that a solution to the problems with this issue would be to not filter out the connections in CopyAction.run, but pass them to CopySnapshot, and use "them" instead of trying to secondguess what the user meant in CopySnapshot.getConnectionsToCopy()?

Solving this issue would then be a matter of checking for hidden connections in nested elements in getTopLevelObjectsToCopy between containers and their children, and add them to the list of selection connections, not?

The downside is that the user have to explicitly select all visible connections that he/she wants copied.... I personally believe that is less confusing than the current approach, where the connections are taken from the DiagramModel, not the selection ... but that is your call, of course.

I have spent some time trying to understand CopySnapshot in relation to #60 ... I don't mind giving this a shot, if you think you could "mentor" my pull requests...?

@mbd-dbc-dk
Copy link
Contributor

BTW: If a container is selected, all copy and delete works both on the container and the elements it contains, even though the contained elements are not visible showing up with handles. This is, i believe, correct behaviour.

I think that is worth documenting though - I have made a mental note.

@Phillipus
Copy link
Member Author

Working on this for next version. Explicit connections are made when nesting.

The behaviour as Mads identifies is one that users want (all copied objects also get their connections along as well). The new code supports both ways of doing it, so we can close this issue and start a new one if needed.

jbsarrodie referenced this issue Nov 28, 2016
* This solves the issue of trying to hide connections to connections that are also hidden
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants