| Feature request [message #1827296] |
Tue, 12 May 2020 14:08  |
|
| References in identifiers[ 0 votes ] |
|---|
| 1. | Yes, I would appreciate that feature |  0 / 0% | | 2. | No, that will only confuse me | 0 / 0% |
I would like to request a new feature.
Element names should be enabled to reference any number of identifiers as part of the name.
An Example
uml::Package: Role1
uml::Actor: Actor-{uid of Role1}
uml::Package: Assumptions -- Actor -- {uid of Role1}
In the above case, {uid of Role1} shall be evaluated to Role1. In the case you rename the package Role1 to FeatureRequester, then {uid of Role1} shall evaluate to FeatureRequester.
/Carsten
PS The reference mechanism available with comments might be adapted to implement that feature. Most likely the existing implemtation is not aware of recursion.
|
|
|
|
| Re: Feature request [message #1827311 is a reply to message #1827300] |
Tue, 12 May 2020 20:22  |
|
Could be. I have a damn lot of customers, that in the end want the design printed on paper. Three bunches of paper then after successful review are manually signed by three or more people page for page. Two bunches get archived in specially air conditioned archives with at least 200km distance in between. One is the presence copy.
And in the case the official reference is printed paper, naming conventions help a lot.
/Carsten
|
|
|
| Re: Feature request [message #1827328 is a reply to message #1827311] |
Wed, 13 May 2020 07:38 |
 Yoann Farré
Messages: 235
Registered: November 2017 |
Senior Member |
|
|
Hello,
I agree that it can be very useful.
I agree with Ed that renaming refactoring can be seriously challenging. With the purpose to make it easier, I proposed a similar feature previously, not for the names but for the text contents (like in Opaque Behavior or Opaque Expression) : Bug 549877
It is not exactly the same feature but I think they can be evaluated together, that's why I share the link.
Regards.
Yoann.
EDIT : My vote can not be taken into account. I don't know why.
[Updated on: Wed, 13 May 2020 07:41] Report message to a moderator |
|
|
| Re: Feature request [message #1827333 is a reply to message #1827328] |
Wed, 13 May 2020 09:08 |
|
Hi Ed,
Hi Yoann,
I have not stated implementation will be trivial. In German we tend to say the rhyme: "Rekursiv geht meistens schief.". Translated it means: recursion is error prone.
Furthermore an, at creation time resolvable reference can become unresolvable during lifetime due to a referenced element has been renamed in way causing a cyclic dependency. Or even simpler if a referenced element is deleted. I am fully aware of this. In the case a reference becomes unresolvable, I would expect a message stating what has happened and that the reference does not get resolved until it becomes resolvable again. Does not get resolved simply means the "{uid of element}" is shown plain vanilla.
/Carsten
[Updated on: Wed, 13 May 2020 09:22] Report message to a moderator |
|
|
|
|
| Re: Feature request [message #1827338 is a reply to message #1827337] |
Wed, 13 May 2020 11:23 |
|
Hi Ed,
uid might be what becomes the xmi:id in the UML file. An unique identifier somehow generated by Papyrus that cannot be altered by the user. Or to be more exact: At least cannot be altered by the users by means provided by Papyrus. The means might be provided by the Eclipse installation (i.e. the generic text editor or the webXML editor), but not by Papyrus itself. I presume users editing the UML file directly with some text editor or XML editor or else to be aware of what they do.
/Carsten
|
|
|
|
| Re: Feature request [message #1827365 is a reply to message #1827361] |
Wed, 13 May 2020 18:32 |
|
Hi Ed,
I am very sorry about that, but obviously as the attached screenshot shows the Papyrus comment editor uses the xmi:id as uid for references. That makes me somehow believe, there is some means to get the xmi:id within Papyrus.
/Carsten
Attachment: uid.PNG
(Size: 194.91KB, Downloaded 75 times)
|
|
|
|
| Re: Feature request [message #1827375 is a reply to message #1827371] |
Wed, 13 May 2020 19:48 |
|
Hi Ed,
no it not the "If the comment needs a link to an element" case. The {@....} is evaluated to the element's name. If you take a look at the comment text in the diagramme in the new screenshot, in that case you will see "User" instead of "{@...}". "User" is underlined to show it is an evaluated reference.
As I really like this feature, I will NOT file it as an issue ;-)
/Carsten
-
Attachment: uid2.PNG
(Size: 185.63KB, Downloaded 83 times)
|
|
|
|
| Re: Feature request [message #1827405 is a reply to message #1827399] |
Thu, 14 May 2020 08:11 |
|
Hi Ed,
I have to further think on your statement. What is currently unclear to me, how utilities working on the emitted XMI (i.e. Eclipse Obeo Acceleo) can access self.name. Accessing xmi_id attributes is straight forward for such utilities.
/Carsten
|
|
|
|
| Re: Feature request [message #1827431 is a reply to message #1827428] |
Thu, 14 May 2020 11:50 |
|
Hi Ed,
yes, should be possible. A qualified name shall also be unique within a model. Using qualified name instead of xmi:uid only forces the tools to unmarshal the XMI prior to processing and to operate on an object model. But this is -- hopefully -- the case with at least Eclipse Obeo Acceleo.
OK, yes Ed, I am now fully d'accord with you on xmi:id attributes. As purely technically required unique identifiers by the marshaling process these should not be exposed to the tool's user. Furthermore a qualified name should qualify as -- as my mind tells me currently -- a drop-in replacement.
/Carsten
EDIT s/shall/should/
[Updated on: Thu, 14 May 2020 11:54] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.04722 seconds
] 
Search
Help
Register
Login
Home
