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

feat(dia.Graph): add transferCellEmbeds() and transferCellConnectedLinks() #2752

Merged
merged 10 commits into from
Oct 23, 2024

Conversation

MartinKanera
Copy link
Contributor

@MartinKanera MartinKanera commented Sep 6, 2024

Description

Add graph.transferCellEmbeds() and graph.transferCellConnectedLinks().
Change the dia.Cell.embed method to accept opt.reparent.

Documentation

transferCellEmbeds()

graph.transferCellEmbeds(sourceCell, targetCell [, opt]);

Transfer embedded cells of sourceCell to targetCell.

transferCellConnectedLinks()

graph.transferCellConnectedLinks(sourceCell, targetCell [, opt]);

Transfer all the links connected to sourceCell to targetCell.

embed()

...

The opt.reparent option can be set to true to transfer the embedded cells from their current parent to the new parent.

Copy link
Contributor

@kumilingus kumilingus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both methods should run inside a batch:
transfer-links
transfer-hiearchy

@zbynekstara
Copy link
Contributor

Thoughts on the naming of the functions:

  • graph.transferCellHierarchy is not ideal because it makes it seem that target cell will not be modified (only passively receiving the children of source element), but I have trouble coming up with a better name. I don't think the word cellHierarchy makes it obvious that target will also be reparented to source's parent. I don't think these two separate actions can be captured by a single word - perhaps the name should be split to describe the two actions separately and more precisely, like graph.transferCellEmbedsAndReparent?
  • graph.transferCellLinks is okay, but since we already have cell.getConnectedLinks, graph.transferCellConnectedLinks would be more consistent

@MartinKanera
Copy link
Contributor Author

Thoughts on the naming of the functions:

  • graph.transferCellHierarchy is not ideal because it makes it seem that target cell will not be modified (only passively receiving the children of source element), but I have trouble coming up with a better name. I don't think the word cellHierarchy makes it obvious that target will also be reparented to source's parent. I don't think these two separate actions can be captured by a single word - perhaps the name should be split to describe the two actions separately and more precisely, like graph.transferCellEmbedsAndReparent?
  • graph.transferCellLinks is okay, but since we already have cell.getConnectedLinks, graph.transferCellConnectedLinks would be more consistent

transferCellEmbeds (add Cell.embed opt.reparent) and transferCellConnectedLinks

@MartinKanera MartinKanera changed the title feat(dia.Graph): add transferCellHierarchy() and transferCellLinks() feat(dia.Graph): add transferCellEmbeds() and transferCellConnectedLinks() Oct 3, 2024
@kumilingus kumilingus merged commit b62479c into clientIO:master Oct 23, 2024
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants