v15.2 – [Ctrl+Shift+Alt+V] to paste link for “Diagram Owned” items

[Paolo F Cantoni]

As many of you will know.  I'm not enamoured of the "Diagram Owned" objects.  Apart from the Title Block element, I don't see any need for them.  In fact, for our modelling, they seriously get in the way!

We have do develop all sorts of "behind the scenes" processes to enable us to convert the individual instances (of the SAME thing) to links to the root vertex and then purge the excess (now orphaned) objects from the repository.

Our latest "bad boy" is the Navigation Cell.  They are cute things, but when we discovered that they will create new instances when we copy them from diagram to diagram (because, believe it or not, we want to return to the same diagram) we needed to solve this.  Why?  because we wanted to be able to set the default appearance/name and other properties and have all the cells conform like any other linked diagram vertex.

Anyway, it occurred to me that it would be MOST useful for those of us who abhor "Diagram Owned" objects to be able to "Paste as Link" (regardless of the ownership).  I propose that the currently unassigned, by default,  [Ctrl+Shift+Alt+V]^[1] be used (in conjunction with a context menu item) to perform that function for these diagram owned items.

Thoughts?
Reported,
Paolo

^[1] I would have preferred [Ctrl+Alt+V], but that's already assigned to the (unused by us) "Validate Current Package" function.

[Eve]

As I said last time you requested this.

Currently placing those on multiple diagrams can have negative impacts such as the item being accidentally deleted. That's why 15.2 has become stricter so that they are forced to be a unique element for each diagram.

We are looking at including all of them in the browser, which will mean you can share the one element across multiple diagrams. That will also supersede this request. There won't be a temporary change to make it easier for you to break the rules that the tool sets for your safety.

[qwerty]

The "Navigation Cell" is probably some sort of Comment (for which the Sparxians use the word Note). An UML Comment

is a textual annotation that can be attached to a set of Elements.

Hiding that Comment (in the browser) is the Sparxian way. And now not to allow instances of the same Comment on multiple diagrams is the next step? Because they belong to a diagram? For safety reasons? What am I getting wrong here?

q.

[Paolo F Cantoni]

As I said last time you requested this.

Currently placing those on multiple diagrams can have negative impacts such as the item being accidentally deleted. That's why 15.2 has become stricter so that they are forced to be a unique element for each diagram.

We are looking at including all of them in the browser, which will mean you can share the one element across multiple diagrams. That will also supersede this request. There won't be a temporary change to make it easier for you to break the rules that the tool sets for your safety.

If they are included in the browser, which I applaud, does that mean they WON'T be "owned by the diagram"?
If so, then I guess [Ctrl+V] will paste the link.  If not, then my request is still valid.
Also, I note in another dialog (I found it last week, but didn't take note of the circumstance), there is an explicit [Shift+V] which says "Paste as Link" but it doesn't for these "Diagram Owned" objects.  That option needs to be disabled for these items.

Lastly, we are allowed to remove "Strict Connector Syntax" to allow us to "break the rules that the tool sets for our safety".  I put this in the same class.

Paolo

[Eve]

I'll emphasize looking at. I'm not telling you that it will happen.

There are a number of places where EA treats those elements as owned by the diagram. I'm sure you can imagine the kind of issues that could occur based on that. Things like deleting an apparently empty package removing places where they have been used. It becomes a data integrity issue rather than a style issue like the strict connector rules.

We are looking into how we can show those elements in the browser and allow them to be used on many diagrams. Despite the impression of some here, we aren't going to release something that we aren't confident in. For now, the safest approach we can take is to prevent elements that don't appear in the browser being shared across multiple diagrams. If you want to force it anyway, that's your decision. If we change that behavior in the future, I would recommend ensuring that all users are updated to a version that allows that behavior.

[Paolo F Cantoni]

[SNIP]
If you want to force it anyway, that's your decision. If we change that behavior in the future, I would recommend ensuring that all users are updated to a version that allows that behavior.

(my emphasis)
Since we are already successfully converting them to real (linked) objects - albeit that they aren't visible in the browser - our users already are.  Objects behave consistently!

But yes, we'd update them appropriately.
Paolo

[Eve]

Since we are already successfully converting them to real (linked) objects - albeit that they aren't visible in the browser - our users already are.  Objects behave consistently!

All that means is that you haven't encountered the issues or haven't attributed the cause of issues you have encountered to that behavior.

[Paolo F Cantoni]

Since we are already successfully converting them to real (linked) objects - albeit that they aren't visible in the browser - our users already are.  Objects behave consistently!

All that means is that you haven't encountered the issues or haven't attributed the cause of issues you have encountered to that behavior.

Alternatively, it could mean that we HAVE encountered the issues with the current implementation and explicitly "designed them out" with our background processing and technology definition.   

Paolo