You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think that the DotTopologySerializer exports the links twice. Although not harmful, it is not correct.
Also, in this method, we use the directed links to perform the export. Since we don't use digraph-parser anymore, I suppose DOT would allow us to use the Topology's orientation (Topology.getLinks()).
Side note
For a specific project, I recently needed to modify the serializer outputs a Link. Since the exportToString method is very monolithic, I had to copy paste the whole class and modify it. Maybe segmenting it a bit into protected methods (at least something like exportLinkToString(Link)) could help?
The text was updated successfully, but these errors were encountered:
@pictavien , since you have recently been the main contributor of the DotTopologySerializer, I suppose that you are the best suited to check my claims and correct what actually needs to be?
Ok. I take over it.
There is a bug. But, the previous version of 'exportToString', tried to handle the case where one add directed links to an undirected topology. To this purpose, it generates both kind of links (edges and arcs). When the topology is reloaded, addLink check if the arc or edge already exists, in which case the link is ignored. So we have to export 3 kinds of topology:
1/ A simple undirected topology where 2*(number of arcs) = number of edges. In this case we export only edges.
2/ A simple directed topology for which we export only arcs.
3/ An undirected topology extended with directed links.
Shall we handle this latter case ?
In my opinion, we are trying to support borderline cases. I think I remember discussions in which going back and forth between DIRECTED and UNDIRECTED is not officially supported. It would then be the user's responsibility to set the topology's orientation right.
Anyway, I suppose we can still do something like:
directed topologies
-> exported as DIRECTED
undirected topologies
2*(number of arcs) == number of edges
-> exported as UNDIRECTED
2*(number of arcs) != number of edges
-> exported as DIRECTED
Adding extra infos, like we used to, would not be understood by DOT parsers we don't control.
Main Issue
I think that the
DotTopologySerializer
exports the links twice. Although not harmful, it is not correct.Also, in this method, we use the directed links to perform the export. Since we don't use
digraph-parser
anymore, I suppose DOT would allow us to use theTopology
's orientation (Topology.getLinks()
).Side note
For a specific project, I recently needed to modify the serializer outputs a
Link
. Since theexportToString
method is very monolithic, I had to copy paste the whole class and modify it. Maybe segmenting it a bit into protected methods (at least something likeexportLinkToString(Link)
) could help?The text was updated successfully, but these errors were encountered: