You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When copying a ComponentDefinition "parent" that has a sub-Component "child" into a new namespace, if the definition property of "child" refers to a ComponentDefinition in the same document, then the definition property of the copy of "child" appears to be imported into the same namespace as the copy of "child". As a user, I would expect the copy of "child" to retain the same definition property as the original "child". I would only expect this definition property to be copied into a different namespace if the ComponentDefinition to which it refers is also copied into a new namespace, which it currently is not. Maybe there should be an option to recursively copy in this manner. Here is some example code:
This one is probably a sticky wicket. It will require a two-pass approach to copying that isn't set up in the current recursive implementation. The first pass would do all the renaming and create a map of old-to-new names. The second pass would then update references based on the renaming map. There may be other approaches as well.
When copying a ComponentDefinition "parent" that has a sub-Component "child" into a new namespace, if the definition property of "child" refers to a ComponentDefinition in the same document, then the definition property of the copy of "child" appears to be imported into the same namespace as the copy of "child". As a user, I would expect the copy of "child" to retain the same definition property as the original "child". I would only expect this definition property to be copied into a different namespace if the ComponentDefinition to which it refers is also copied into a new namespace, which it currently is not. Maybe there should be an option to recursively copy in this manner. Here is some example code:
The text was updated successfully, but these errors were encountered: