structurizr / export

Export models and views to external formats.

Home Page:https://docs.structurizr.com/export

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

dashed styles not shown in dynamic views when configured as sequence diagrams

dgutson opened this issue · comments

Please consider

workspace "Test Product Architecture" "Model of the Test Platform." {

    !identifiers hierarchical

    model {
        ss = softwaresystem "SS" "Software System" {
            cont1 = container "Container1" {
                comp11 = component "Component11"
                comp12 = component "Component12"

                comp11 -> comp12 "one\ntwo" "" "dashed"
            }

            cont2 = container "Container2" {
                comp21 = component "Component21"
            }

            cont1.comp11 -> cont2.comp21 "Relation1" "" "dashed"
            cont1.comp12 -> cont2.comp21 "Relation2"
        }
    }

    views {
        properties {
            plantuml.sequenceDiagram true
        }

        container ss {
            include *
            autoLayout
        }

        component ss.cont1 {
            include *
            autoLayout
        }

        dynamic ss.cont1 {
            ss.cont1.comp11 -> ss.cont1.comp12
        }

        styles {
            relationship "dashed" {
                dashed true
                style dashed
            }
        }

        theme default

    }
}

(sorry long example)

This is generated:
image

Note that the arrow is not styled as dashed.

This is a double dash in websequencediagrams/plantUML: a --> b

My use case is: when the initiating arrow has not the same text that the returning arrow.
For example

a->b "send data"
b->a "return results"

I know structurizr shows the dotted lines when the source/dest are inverted and the text is the same. I need the same behavior but when the text is different.

This is more specific than my original title about honoring the style in sequence diagrams. I just need dashed arrows for returning messages when text is different.

I no longer need this because the solution of #32 is good enough.