Hello,
I would like to propose a feature whereby string arguments to various shape script
drawing methods are modified to accept
property references.
As far as I know, only the
print*() methods permit this today.
My use case is that I need to draw some diagrams for non-UML readers...
Hear me out.
My use case is that I need to draw some diagrams for non-UML readers, wherein I need to show legal ownership of various things. The simplest and cleanest way to do that is to use the logos of the various companies and institutions involved.
However, it isn't possible for me to create a stereotype which outputs a logo in a decoration with something like
Image("#TAG:Logo#", 0, 0, 100, 100);because
Image() only accepts a simple hard-coded lookup string, rendering it virtually useless.
If
Image() could accept a tag, I could create my stereotype with a tag which refers to an image and just set it in each element of that stereotype, easy-peasy.
But it's not just tags that could be used here. Other properties, like the name or alias, could be used as well. Thus, if you named an element "Sparx" it would be shown with one logo, and if you renamed it "Microsoft" the logo would change.
In addition to
Image() there are several other methods which take a string. Some of those could benefit from property lookup, others not. At a glance, I'd say:
- AppendCompartmentText() -- yes.
- SetCompartmentName() -- not as clear. Possibly too complex, and I don't see a great need.
- SetLineStyle() -- this string is actually an enum, so the same effect can be achieved with an enum tag and a bunch of ifs. Not needed, though possibly nice to have.
- SetOrigin() -- another enum.
- HideLabel(), ShowLabel() -- not obvious, and the documentation hints that this is a hack which might be best left undisturbed. Anyway it's another enum.
A few theoretical points.
You could argue that wrt
Image() the current behaviour is a bug. Shape scripts apply to stereotypes, and stereotypes define categories -- not individuals.
If not a bug, then at least an overly limited feature, because it in fact allows you to include in a shape only images which relate to the category. You can't add an image which relates to the individual because the image is hard-coded in the shape script, and the shape script is a property of the stereotype.
Allowing property parsing in this method would allow you to add individual "visual properties" in addition to any category-defined ones. And I would argue that is a more correct approach to UML extension.
/Uffe
