Add elements to a view based upon tag(s) about dsl

[simonbrowndotje]

It should be possible to add a feature to do something like this though:

container springPetClinic {
    include "tag:tag 1"
    autoLayout
 }

[simonbrowndotje]

That's now available ... this will work:

container springPetClinic "All_Containers_tag1_expectation2" {
    include "element.tag==tag1"
    exclude * -> *
    include "relationship.tag==tag1"
    autoLayout
}

[simonbrowndotje]

Correct, it's only available on the demo page at the moment - there should be a new CLI release in the next week or so.

[simonbrowndotje]

CLI v1.9.0 is now available -> https://github.com/structurizr/cli/releases/tag/v1.9.0

(the tags functionality still isn't implemented for deployment views, but this will follow)

[simonbrowndotje]

Correct, yes ... with your examples, something like this:

container springPetClinic "All_Containers_tag1_expectation" {
    include "element.tag=tag1"
    autoLayout
}

container springPetClinic "All_Containers_tag2_expectation" {
    include "element.tag=tag2"
    autoLayout
}

I'm thinking that a syntax of element.tag= allows for similar features in the future, perhaps relationship.tag=, or element.property.name=value (somebody was asking about this recently).

[simonbrowndotje]

This is now available to try at https://structurizr.com/dsl:

workspace "Amazon Web Services Example" "An example AWS deployment architecture." {
    model {
        springPetClinic = softwaresystem "Spring PetClinic" "Allows employees to view and manage information regarding the veterinarians, the clients, and their pets." "Spring Boot Application"{
            app = container "Mobile App" "Show information regarding the veterinarians, the clients, and their pets." "android" "Mobile App, tag1, tag2"
            api1 = container "API 1" "API 2" "Java and Spring Boot" "tag1"
            api2 = container "API 2" "API 2" "Java and Spring Boot" "tag2"
            database = container "Database" "Stores information regarding the veterinarians, the clients, and their pets." "Relational database schema" "Database, tag1"
        }
        thirdPartyApi1 = softwaresystem "Third-Party API 1" "" "tag1"
        thirdPartyApi2 = softwaresystem "Third-Party API 2" "" "tag2"
        
        app -> api1 "manages data" "AWS API Gateway" "tag1"
        app -> api2 "manages data" "AWS API Gateway" "tag2"
        api1 -> database "Reads from and writes to" "JDBC/SSL" "tag1"
        api1 -> thirdPartyApi1 "Get 3rd pary data" "HTTP" "tag1"
        api2 -> thirdPartyApi2 "Get 3rd pary data" "HTTP" "tag2"
    }
         
    views {
        container springPetClinic "All_Containers_tag1_expectation1" {
            include app api1 database thirdPartyApi1
            autoLayout
        }
        
        container springPetClinic "All_Containers_tag2_expectation1" {
            include app api2 thirdPartyApi2
            autoLayout
        }
        
        container springPetClinic "All_Containers_tag1_expectation2" {
            include "element.tag==tag1"
            autoLayout
        }
        
        container springPetClinic "All_Containers_tag2_expectation2" {
            include "element.tag==tag2"
            autoLayout
        }
        
        styles {
            element "Element" {
                shape roundedbox
                background "#ffffff"
            }
            element "Database" {
                shape cylinder
            }
            element "Mobile App" {
                shape MobileDeviceLandscape
            }
            element "Infrastructure Node" {
                shape roundedbox
            }
        }

        themes https://static.structurizr.com/themes/amazon-web-services-2020.04.30/theme.json
    }
}

[simonbrowndotje]

It hopefully will be, although it requires a little more thought based upon the way that the current implementation of include for deployment views works (it expects deployment nodes).

[simonbrowndotje]

I've added support for including relationships by tag now too, with the following DSL definition as an example:

workspace {

    model {
        softwareSystem = softwaresystem "Software System" {
            webApplication = container "Web Application" 
            database = container "Database"
        }

        webApplication -> database "Reads from and writes to" "JDBC/SSL" "Tag 1"

        deploymentEnvironment "Live" {
            deploymentNode "Amazon Web Services" {
                route53 = infrastructureNode "Route 53"
                elb = infrastructureNode "Elastic Load Balancer"
                deploymentNode "EC2" {
                    webApplicationInstance = containerInstance webApplication
                    containerInstance database
                }

                route53 -> elb "Forwards requests to" "HTTPS" "Tag 2"
                elb -> webApplicationInstance "Forwards requests to" "HTTPS" "Tag 3"
            }
        }
    }
         
    views {
        deployment * "Live" {
            include "element.type==InfrastructureNode"
            include "element.tag==Container Instance"
            exclude * -> *
            include "relationship.tag==Tag 1"
            include "relationship.tag==Tag 2"
            include "relationship.tag==Tag 3"
            autolayout lr
        }
   }
   
}

Does that work as you'd expect? Also, what's your use case for including relationships by tag?

[simonbrowndotje]

That's the intended behaviour. From https://structurizr.com/help/filtered-views:

The benefit of using filtered views is that element and relationship positions are shared between the filtered views.

Filtered views are designed to share the same underlying layout, so that they can be easily compared side-by-side (e.g. before and after, current and future state, etc).

[juanrferia]

Thanks for the clarification. Then, is there any way to get the view I want based on element tags?

[simonbrowndotje]

Not with tags, I'm afraid.

[juanrferia]

That feature would be great! I would suggest it supporting multiple tags. Thanks

[simonbrowndotje]

I think I'd like to do something like this:

• include elements that have the specified tag: include "tag:tag 1"
• include elements that have all of the specified tags: include "tag:tag 1,tag 2"

So these two blocks would potentially yield different results:

container springPetClinic {
    include "tag:tag 1"
    include "tag:tag 2"
    autoLayout
 }

container springPetClinic {
    include "tag:tag 1,tag 2"
    autoLayout
 }

Thoughts?

[juanrferia]

Sounds great. So, the first example would include all elements with tag tag1 or tag2, while the second example would include all elements having both tag1 and tag2. Right?

[juanrferia]

Awesome! Thanks

[juanrferia]

Nice! Thanks for implementing it so fast. Quick one: in case I want to pick both elements and relationships with the same tag 'tag1', should I use "tag==tag1" directly?

[simonbrowndotje]

Probably not. For convenience, whenever you add an element to a view, any relationships from/to that element are also added to the view. So you're probably going to end up doing something like this:

include "element.tag==tag1"
exclude * -> *
include "relationship.tag==tag1"

I'll push another version up to the demo page once the relationship.tag== expression is supported.

[juanrferia]

Is this feature also supported in deployment views?

[simonbrowndotje]

This commit adds support for static views.

[juanrferia]

Cool! It is not live yet, right? I was trying including/excluing via relationship tags

[dgradl-fl]

When is this release expected?

[simonbrowndotje]

Hopefully next week.

[MTomBosch]

Is the tag support available for dynamic views?

[simonbrowndotje]

It's not ... since you're adding instances of relationships from the static model in a specific order, I'm not sure that adding relationships based upon tags is very useful.

[juanrferia]

Hi Simon, do you have a ticket for enabling this feature in deployment views? If not, can you share the status? Thank you!

[simonbrowndotje]

I stashed the code to release support for static views, but an initial version is running at https://structurizr.com/dsl ... let me know what you think.

[MTomBosch]

It's not ... since you're adding instances of relationships from the static model in a specific order, I'm not sure that adding relationships based upon tags is very useful.

Yes, you are right. Since I am anyway controlling via the relations which elements are shown the inclusion via tags makes no sense at all :)

[juanrferia]

I stashed the code to release support for static views, but an initial version is running at https://structurizr.com/dsl ... let me know what you think.

Almost perfect! Including elements by tag is working, but I cannot include relationship by tags. Can you check? Thanks!

[simonbrowndotje]

Unfortunately it's not almost perfect ... on writing the unit tests, I found the initial version of include element.tag==X support for deployment views didn't work in all situations. For example, the previous expression could be interpreted to include:

• software system instances that have a tag of X
• instances of software systems that have a tag of X

These are very different, and there's no way to distinguish what the user was really looking for. So I've made some enhancements. By default, include element.tag==X will include both the cases above, as I think this is more likely the functionality that people would expect.

But you can override it by specifying the type of the element you're interested in, for example:

• include "element.type==Container && element.tag==X"
• include "element.type==ContainerInstance && element.tag==X"

This is running at https://structurizr.com/dsl ... please take a look and let me know if it still works for you.

[juanrferia]

Hi Simon. Looks great!
My usecase for including relationships: I found some of my deployment diagrams difficult to read beacuse they included too many relationships. I decided to hide all relationships between containers and systems and, instead, I created just a few simple relationships bettween deployments nodes to represent them as an abstaction and make it clear.
Thanks a lot!

[AndreiPashkin]

For future readers - syntax has changed, now you have to write exclude "* -> *" and not exclude * -> *.