Is it possible to extend workspace model?

[spirom64]

Currently I'm working on a custom library able to export workspace model as DSL (decided not to implement it as a custom exporter inside Structurizr since there've already been some discussions on this (#327 for example) hinting it might be better to implement it as a stand-alone library). There were basically no problems with restoring initial DSL for elements and groups, but there were some with relationships and views:

1. In the case of relationships:

   • there is currently no information in the model about element and group, where this relationship was declared - are there any contraindications to add this info to Relationship class and populate it based on current context during DSL parsing?
   • there is also no obvious way to determine if relationship was not declared in initial DSL and was generated implicitly - the same question as above, it seems like it would be totally possible to add some flag with this info

2. In the case of views:

   • there is no information about initial filtering expressions (includes and excludes) used to populate views with elements and relationships - is is possible to store this info in View model?

The main question is as follows - are there any objections or contraindications to add the info above to workspace models? If there are no I'll be happy to implement all needed changes and make PR :)

It's also totally possible that I've missed some of the info described above and it's already accessible somehow - in this case I would be very grateful if you give me a hint how to extract it based on current model

[simonbrowndotje]

Currently I'm working on a custom library able to export workspace model as DSL

What's your use case is for this?

Rebuilding the DSL is essentially an impossible task, particularly when you start considering the impact of scripts, etc. Assuming that the JSON workspace was generated via the Structurizr tooling, the original DSL is stored in a workspace property named structurizr.dsl (screenshot attached; it's base64 encoded), so perhaps you could just use this?

[spirom64]

Hello, Simon!

First of all, thank you for your quick reply!

The main use case for this lib is to use it in automation pipelines actualizing DSL models based on some topology information (also collected automatically based on telemetry data for example). Main types of updates - addition of some elements, addition of corresponding relationships and maybe updating some views, these pipelines don't store or change any scripts, docs, ADRs etc. And since workspaces are expected to be updated, initial DSL stored in properties wouldn't be enough unfortunately

Considering only these tasks it seems like exporting workspaces obtained in this way becomes quite possible, except for lack of some data. But extending models with this data only to be able to export workspaces as DSL in some special cases seems to be at least slightly controversial solution, thus I've decided to start this discussion :)