-
Notifications
You must be signed in to change notification settings - Fork 419
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
Make editor truly multi-root aware #600
Labels
enhancement
New feature or request
Comments
nikku
added a commit
that referenced
this issue
Dec 10, 2021
It is the canonical partner to #addRootElement and friends. Related to #600
nikku
added a commit
that referenced
this issue
Dec 10, 2021
This adds the capability to add multiple root elements to the Canvas. As a side-effect, it drops our leaky plane abstraction from the public API. The following existing APIs make the magic happen: * `Canvas#addRootElement` - add a root element without showing it * `Canvas#removeRootElement` - remove a root element * `Canvas#setRootElement` - set to a specific root element; for backwards compatibility the add-during-set semantic is kept * `Canvas#getRootElements` - returns a list of root elements that can be switched to Under the hood we continue to rely on root element specific layers. However, we clean these layers up once the root element is removed. Closes #600 BREAKING CHANGES: * All plane related APIs got removed, use the newly introduced `(add|set)RootElement` APIs to accomplish the same thing. * Every root element gets it's own layer now; there is no magic re-use of the BASE_LAYER happening anymore. * `setRootElement` does not have single root semantics anymore. As such, it does not blow up if a non-existing root is being passed; rather, it adds that new root and shows it.
nikku
added a commit
that referenced
this issue
Dec 10, 2021
This adds the capability to add multiple root elements to the Canvas. As a side-effect, it drops our leaky plane abstraction from the public API. The following `Canvas` APIs make the magic happen: * `Canvas#addRootElement` - add a root element without showing it * `Canvas#removeRootElement` - remove a root element * `Canvas#setRootElement` - set to a specific root element; for backwards compatibility the add-during-set semantic is kept * `Canvas#getRootElements` - returns a list of root elements that can be switched to Under the hood we continue to rely on root element specific layers. However, we clean these layers up once the root element is removed. Closes #600 BREAKING CHANGES: * All plane related APIs got removed, use the newly introduced `(add|set)RootElement` APIs to accomplish the same thing. * INTERNAL: Every root element gets it's own layer now; there is no magic re-use of the BASE_LAYER happening anymore. * `setRootElement` does not have single root semantics anymore. As such, it does not blow up if a non-existing root is being passed; rather, it adds that new root and shows it. * `setRootElement` has on `override` semantics anymore. To replace the current root, set a new root and remove the old one.
bpmn-io-tasks
bot
added
in progress
Currently worked on
and removed
needs review
Review pending
labels
Dec 10, 2021
nikku
added a commit
that referenced
this issue
Dec 10, 2021
This adds the capability to add multiple root elements to the Canvas. As a side-effect, it drops our leaky plane abstraction from the public API. The following `Canvas` APIs make the magic happen: * `Canvas#addRootElement` - add a root element without showing it * `Canvas#removeRootElement` - remove a root element * `Canvas#setRootElement` - set to a specific root element; for backwards compatibility the add-during-set semantic is kept * `Canvas#getRootElements` - returns a list of root elements that can be switched to Under the hood we continue to rely on root element specific layers. However, we clean these layers up once the root element is removed. Closes #600 BREAKING CHANGES: * All plane related APIs got removed, use the newly introduced `(add|set)RootElement` APIs to accomplish the same thing. * INTERNAL: Every root element gets it's own layer now; there is no magic re-use of the BASE_LAYER happening anymore. * `setRootElement` does not have single root semantics anymore. As such, it does not blow up if a non-existing root is being passed; rather, it adds that new root and shows it. * `setRootElement` has on `override` semantics anymore. To replace the current root, set a new root and remove the old one.
bpmn-io-tasks
bot
added
needs review
Review pending
and removed
in progress
Currently worked on
labels
Dec 10, 2021
nikku
added a commit
that referenced
this issue
Dec 10, 2021
This adds the capability to add multiple root elements to the Canvas. As a side-effect, it drops our leaky plane abstraction from the public API. The following `Canvas` APIs make the magic happen: * `Canvas#addRootElement` - add a root element without showing it * `Canvas#removeRootElement` - remove a root element * `Canvas#setRootElement` - set to a specific root element; for backwards compatibility the add-during-set semantic is kept * `Canvas#getRootElements` - returns a list of root elements that can be switched to Under the hood we continue to rely on root element specific layers. However, we clean these layers up once the root element is removed. Closes #600 BREAKING CHANGES: * All plane related APIs got removed, use the newly introduced `(add|set)RootElement` APIs to accomplish the same thing. * INTERNAL: Every root element gets it's own layer now; there is no magic re-use of the BASE_LAYER happening anymore. * `setRootElement` does not have single root semantics anymore. As such, it does not blow up if a non-existing root is being passed; rather, it adds that new root and shows it. * `setRootElement` has on `override` semantics anymore. To replace the current root, set a new root and remove the old one.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
As discussed with @marstamm there is the potential to clean up the root element vs. plane behavior and make the editor truly multi-root aware:
SubProcess
in BPMN) may be both represented as a root element (with children) as well as an element (collapsed without children or expanded)This shall be a topic to investigate.
Describe the solution you'd like
Describe alternatives you've considered
We can decide to keep the existing
plane <-> root element
duality at the cost of additional complexity, more APIs and so forth.However, simply becoming multi-root aware seems the more sensible way to go in terms of reasonable API evolution.
Additional context
Related to bpmn-io/bpmn-js#1443
The text was updated successfully, but these errors were encountered: