Add tag (=additional stereotype) support, that e.g. specific characteristics can be added to an element

[kirchsth]

In some diagrams I want to display additional details (e.g. component is part of failover) with a different color. PlantUML supports multiple stereotypes, and I would add for the tag an additional stereotype.

E.g. all element are extended with a tag argument

ContainerDb($alias, $label, $techn, $descr="", $sprite="", $tag="")

E.g. the "C4_Deployment Diagram Sample - bigbankplc" has a second DB which is part of failover (this DB is marked with the tag "fallback"). It could be modelled like

@startuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Deployment.puml

skinparam database {
    FontColor<<fallback>> #404040
    BackgroundColor<<fallback>> #c0c0c0
}
...
    Deployment_Node(bigbankdb01, "bigbank-db01", "Ubuntu 16.04 LTS"){
        Deployment_Node(oracle, "Oracle - Primary", "Oracle 12c"){
            ContainerDb(db, "Database", "Relational Database Schema", "Stores user registration information, hashed authentication credentials, access logs, etc.")
        }
    }
    Deployment_Node(bigbankdb02, "bigbank-db02", "Ubuntu 16.04 LTS"){
        Deployment_Node(oracle2, "Oracle - Secondary", "Oracle 12c"){
            ContainerDb(db2, "Database", "Relational Database Schema", "Stores user registration information, hashed authentication credentials, access logs, etc.", $tag="fallback")
        }
    }
...

and the output would look like

I don't know if it can be realized in all scenarios (I have to check it) but could try it.

[adrianvlupu]

Hi, while I understand the need to add custom colors and entities to a C4 Diagram, I think that adding another parameter to the Container procedure will overcomplicate things. How about using the $getContainer procedure instead?

@startuml
!include https://raw.githubusercontent.com/adrianvlupu/C4-PlantUML/latest/C4_Container.puml

skinparam database<<fallback>> {
    FontColor #404040
    BackgroundColor #c0c0c0
}
!unquoted procedure FallbackDatabaseContainer($alias, $label, $techn, $descr="", $sprite="")
database "$getContainer($label, $techn, $descr, $sprite)" <<fallback>><<container>> as $alias
!endprocedure

FallbackDatabaseContainer(db2, "Database", "Relational Database Schema", "Stores user registration information, hashed authentication credentials, access logs, etc.")
@enduml

This is not perfect either because it doesn't show up in the legend but I think it's worth adding stuff like this in the docs. What do you think?

[kirchsth]

Hi, I also didn't like an additional argument, but then I found the "keywords arguments" and think that the additional argument would not complicate the diagram anymore as long it is not used. And if they are used its only additional argument (without empty placeholder).

- this I wouldn't like too
  System(s2, "S2", "", "", "fallback")
  ContainerDb(db2, "backup db", "Oracle", "", "", "fallback")

- but this I think is ok
  System(s2, "S2", $tags = "fallback")
  ContainerDb(db2, "backup db", "Oracle",  $tags = "fallback")

In some architectures I used e.g. 2 identically databases and "fallback" is only a time dependen role. And therefore I would prefer that I can model it with the same elements.

The internal implementation should be simple and not the problem. The second advantage would be that I could reuse the same tag for multiple elements (eg. system and container)

[kirchsth]

@adrianvlupu can you please review my PR #107? I think the functionality itself is ok. Maybe you have better names for concrete macros,... Thank you and best regards Helmut