Please allow adding edges to class members and methods with complex names

Question

Hi! I am using PlantUML to generate simple ER diagrams, utilizing class keyword for describing entities.

Currently there is a way to link two properties or methods using class1::prop -- class2::prop syntax, but it doesn't work with complex property names that contain formatting. 

Here is an example of what I am trying to do:

hide empty methods
hide circle

skinparam linetype ortho

!define PK <size:12><&key></size><b>
!define FK <size:12><&link-intact></size><i>
!define PP <size:12><&caret-right></size>

class "<b> Some dict </b>" as d {
    PK ID        \t\t\t Integer
    PP Name          \t String
}

class "<b> Some entity </b>" as e {
    PK ID       \t\t Integer
    FK Type     \t\t Integer
    PP Some field \t JSON
}

e::Type }-- d::ID

I tried to put full property name in quotes like this:  e::"FK Type \t\t Integer" }-- d::"PK ID \t\t\t Integer", but all I get is a syntax error.

Please allow adding edges to class members and methods with complex names.

Answer 1

This feature is under development, but we fixed several issue in the last beta. We also enhanced it so that you can use in your case.

With this beta: https://dl.dropboxusercontent.com/u/13064071/plantuml.jar

Now, the following diagram is working:

@startuml
hide empty methods
hide circle

'skinparam linetype ortho

!define PK <size:12><&key></size><b>
!define FK <size:12><&link-intact></size><i>
!define PP <size:12><&caret-right></size>

class "<b> Some dict </b>" as d {
    PK ID      \t\t Integer
    PP Name    \t String
}

class "<b> Some entity </b>" as e {
    PK ID       \t\t Integer
    FK Type     \t\t Integer
    PP Some field \t JSON
}

e::Type }-- d::ID

@enduml

Unfortunately, the skinparam linetype ortho does not work very well, and there is nothing we can really do here (all this is managed by Graphviz/Dot).

Well, there may be one solution: we could still request Graphviz/Dot to do B-splines, and then we could transform those B-splines into segment for the drawing.
Not sure that it will give some good drawing. And it needs some work.

Another thing that we can do is to enhance crowfoot drawing to only handle 0/90/180/270 angle (should be easy to do).

Does it sound good to you?

Comments

Thanks for the report.

This is fixed on the online server and with last snapshot.

Alternatively, is it possible to define aliases for members and use them as endpoints for arrows? This would allow using unique names and prevent mismatches.

Actually, the main issue here is to find the right syntax to define aliases for member. It's not as simple as it might sound, so any suggestion is welcome :-)

---

Thanks for the fast reply!

This is fixed on the online server and with last snapshot.

It does work as intended on the example :-) For my more complex diagram, the correct members are linked, but the arrows are not always attached correctly: see this example.

(Sorry for the large example; I had trouble reducing it to a MWE as the entities then move to other places and the issue disappears)

For instance, in this example, arrows from members of entity G are badly placed: the arrow from C is in front of Hs, the one from Hs is in front of Ps and the ones for L and Ps are below the entity.

Actually, the main issue here is to find the right syntax to define aliases for member. It's not as simple as it might sound, so any suggestion is welcome :-)

I was thinking of using the same syntax as aliases for entities or classes : "Class name" as CN, but I don't know if it would be compatible with the current syntax for members.

---

It does work as intended on the example :-) For my more complex diagram, the correct members are linked, but the arrows are not always attached correctly: see this example.

Thanks (again) for the feedback.

This is fixed (again) in last snapshot and on the online server

Tell us if you find other issues!

---

This works wonderfully. Thanks!

---

Hello, the skinparam stil does produce erratic links still, i am not understanding the b-splines suggestion, but should we not talk to the graphviz developers to find a solution that would simply ensure the diagram will be consumable? The whole ability is not usable for me if I do not get a consumable diagram so I revert to draw them with draw.io or lucidchart, which s...

Kind regards