Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to arrow across scope #6

Open
tdihp opened this issue Oct 31, 2014 · 21 comments
Open

How to arrow across scope #6

tdihp opened this issue Oct 31, 2014 · 21 comments

Comments

@tdihp
Copy link

tdihp commented Oct 31, 2014

I want to make arrows across package, for example:

[<package> A|
    [Cat] -> [B.Dog]
]
[<package> B|
    [Dog]
]

Is there any way to do this?

Great project BTW!

@skanaar
Copy link
Owner

skanaar commented Oct 31, 2014

There is no way to do this in nomnoml right now. 😞
Both due to limitations in the current layout engine - and some unresolved questions on syntax.

See the example below for a case where we would have ambiguity. Some concept of "absolute paths" would have to be implemented. I am hesitant as that would be a move away from the nice visual ASCII-art like syntax towards a more programming-language like syntax.

[<package> A|
    [Cat] -> [B.Dog]
    [<package> B|
        [Bird]
    ]
]
[<package> B|
    [Dog]
]

@tdihp
Copy link
Author

tdihp commented Nov 4, 2014

Yes, I see it would be confusing with current syntax, which implicitly create cell when describing connection.

I am hesitant as that would be a move away from the nice visual ASCII-art like syntax towards a more programming-language like syntax.

Plus there will be name escaping (so that dots can be used safely in name), and will get nasty.

I think this can be considered together with #2.

@VWoeltjen
Copy link

Would love to see this too! This is one of the missing features that keeps causing me to fall back to tools other than nomnoml (which I hate to do, because I love nomnoml!)

Honestly, I'd be happy with no extensions to the syntax, and a change to the rules for how names are scoped.

A simple case:

[<package> A | [Vehicle]]
[<package> B | [Car]-:>[Vehicle]]

Right now, this is interpreted as meaning that package B contains both Car and Vehicle. Of course, in this case, the intent is for B to contain just Car, with an association to Vehicle in A. I think this is the more common intent for cases like this; I'd almost never want to have multiple things with the same name in the same diagram (that just sounds confusing!)

If there are use cases for having multiple things of the same name, maybe require that these must be defined on the left-hand side of an association (or without an association at all)? So, if someone really wanted package B to contain both Car and Vehicle (different from A's Vehicle) they could disambiguate by saying:

[<package> A | [Vehicle]]
[<package> B | [Vehicle]; [Car]-:>[Vehicle]]

This avoids introducing new syntax, allocates the simpler syntax for (IMO) the more common case, allows more complex syntax for the less common case, and is even a little discoverable (insofar as it's something you might try - "no, nomnoml, I really do want another Vehicle in B!")

Finally, for more complex ambiguities like:

[<package> A | [Vehicle]]
[<package> B | [Vehicle]]
[<package> C | [Car]-:>[Vehicle]]

...I don't really care what nomnoml does. I've described an incoherent diagram and don't expect a coherent result.

@wizzard0
Copy link

wizzard0 commented Aug 8, 2016

I can also second that this is the only major limitation that prevents using nomnoml at all in place of Gliffy/LucidCharts for me.

@Hunter21007
Copy link

What about somehting like:

[<package> A | [Vehicle]]
[<package> B | [Vehicle]]
[<package> C | [Car]-:>[A:Vehicle]]

where [A:Vehicle] is an absolute path beginning on root of diagram

@skanaar
Copy link
Owner

skanaar commented Sep 1, 2016

The colon ":" is already a UML control character that is used for instances.
[A:Vehicle] means an instance named A of the class named Vehicle.

It also does not address the problems described in #6 (comment)

@Hunter21007
Copy link

Yes, The colon was only example because i am not an UML Expert :)
I have missed the dot in the [B.Dog]
But the dot is a valid accessor in most programming languages i know.
So for me it would be ok

And it is also possible to solve the ambiguity by using absolute paths (maybe)

[<package> A|
    [Cat] -> [B.Dog]
    [Cat] -> [A.B.Bird]
    [<package> B|
        [Bird]
    ]
]
[<package> B|
    [Dog]
]

@ctzurcanu
Copy link

I think all paths should go through the container facade: in a sense nomnoml teaches us to design the class diagram better. So a different approach would be to have package facades (show the connection to package (considering the facade has the same name) an then from package to classes inside of it). The first part nomnoml already does. The second part can be emulated by having a class with the same name as the package inside the package and linking form there.
Of course the reader has to be educated about this convention..

@rms1000watt
Copy link

rms1000watt commented Feb 7, 2017

This would be a great feature. I'd rather use Nomnoml than Mermaid honestly. (I use the 'subgraph' feature in Mermaid.)

@kristofmeixner
Copy link

Really nice tool, but this feature would make it even better.

How about something like the construct PlantUML uses?

[<package> A|[Pirate] as pirate]
[<package> B|[Bird] as bird]
[bird]->[pirate] 

@verbunk
Copy link

verbunk commented Feb 7, 2018

I'm a bit late to the convo but I'd also use this feature for the reason given in #46 Is it still not possible?

@skanaar
Copy link
Owner

skanaar commented Feb 7, 2018

Not a supported feature unfortunately. 😞
It is not supported by the underlying graph-layout-library so there would have to be some work done to replace/extend that. Pull requests are welcome 😄

@queses
Copy link

queses commented Mar 18, 2018

It would be great if this feature wiil be implemented 👍

@LukeTOBrien
Copy link

LukeTOBrien commented Aug 19, 2020

@skanaar Hmm... I see your pickle.... It looks like you use dagre?
You might need to do some serious refactoring to use something more low-level like Snap.svg or something else.

My point in the other post?

When it comes to stacking, could use CSS flexbox?

You could draw the graphs and wrap them in a <div>, that would allow the developed to create their own layout.

@skanaar
Copy link
Owner

skanaar commented Aug 19, 2020

Drawing the graphics is the easy part. Actually calculating the graph layout is a complex task that Dagre does for us.
Here is one of the scientific papers that Dagre is based on http://www.graphviz.org/Documentation/TSE93.pdf
And specifically, "arrow across scope" is really about graph clustering which is described in this paper: https://publikationen.sulb.uni-saarland.de/bitstream/20.500.11880/25862/1/tr-A03-96.pdf

However I think that the latest versions of Dagre do support graph clustering, so this could be implemented. There is just the nitty-gritty details to work out.

@LukeTOBrien
Copy link

... I see, I'll keep quiet then.... Good luck!

@jhonatan1090
Copy link

jhonatan1090 commented Oct 13, 2020

Tell us when it becomes available! Thxx

@skanaar
Copy link
Owner

skanaar commented Oct 13, 2020

@jhonatan1090 You are welcome to help out!
I gladly accept pull requests.

@karlmakepeace
Copy link

Just adding to chorus: "arrow across scope" support would be a great + highly appreciated feature addition. Thanks.

@j333t
Copy link

j333t commented Mar 30, 2024

Why not add one more - to signify absoluteness or ignore grouping?

[fruit]--->[tomato]

This way, it's left to the user to draw arrow to and from any entity, regardless of them being in a group.
I'm sorry if this seems like a stupid suggestion, but this seems like the most obvious.

@jaskij
Copy link

jaskij commented Apr 12, 2024

Looking around, D2 supports containers, even when using Dagre as the layout engine. Maybe check out how they are doing that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests