Support for additionalProperties

[pbazin]

Hello,

Thank you for sharing your project.
Just a question, did you plan to support map definition (https://github.com/OAI/OpenAPI-Specification/blob/3.0.1/versions/3.0.1.md#model-with-mapdictionary-properties).

Again thank you.

[Dave Moten]

Glad it's useful. So, two main cases, a map of string to a simple type and a map of string to a complex type. How do you think they should look when rendered by PlantUML?

[pbazin]

I'm not use to draw uml, but to keep it simple, for string to string map, maybe :
class MainClass { {field} fieldName : Map{string, string} }
For string to object map, does the following works ?
MainClass "fieldName:string" --> "*" MappedClass
This is a simple, comprehensive way, but maybe the next proposition is better :
`
class FieldNameMapDefinition {
{field} key : string
}
FieldNameMapDefinition --> "1" MappedClass : "value"

MainClass --> "*" FieldNameMapDefinition : "fieldName"
`
Even though it is heavier, it is more precise.

[Dave Moten]

Yep that's what I'm thinking too.

I drew up examples:

@startuml

class Thing {
	name: string
	description: string
	properties: string -> string
}

class ThingComplex {
  name: string
  description: string
}

class ThingComplex_Properties {
  key: string {I}
}

class MyValue {
  name: string
  expiry: timestamp
}

ThingComplex --* "*" ThingComplex_Properties: properties
ThingComplex_Properties --> "1" MyValue: value

@enduml

or

[pbazin]

Just a suggestion : maybe ThinkComplex_Properties should be a struct.

[Dave Moten]

as in an anonymous class contained within Thing? How do you do that with PlantUML?

[Dave Moten]

oh you mean this?

[pbazin]

Yes, that what I meant. Don't know if it is a good Idea, but it keeps domain class clearly separated.

[Dave Moten]

Refining a bit more, might look like this:

In general, probably works better to avoid plurals (field name property instead of properties) so we get:

[Dave Moten]

Yes, that what I meant. Don't know if it is a good Idea, but it keeps domain class clearly separated.

In a way the separation and boundaries we want are already indicated by the use of a composition arrow (that diamond thing). As in, could still be a class rather than a struct. I'm happy either way.

[pbazin]

Refining a bit more, might look like this: In general, probably works better to avoid plurals (field name property instead of properties) so we get:

Excellent ! Just a thing : the composition is reversed, I think. The black diamond should be on ThinkComplex side of the relation.

[Dave Moten]

Ah yes, thanks. Diamond on the owner end and arrow on the other.

[Dave Moten]

Diamond fixed. This will be what I aim for then.

@startuml

class Thing {
	name: string
	description: string
	property: string -> string
}

class ThingComplex {
  name: string
  description: string
}

struct "ThingComplex/property" {
  key: string {I}
}

class MyValue {
  name: string
  expiry: timestamp
}

ThingComplex *--> "*" "ThingComplex/property": property
"ThingComplex/property" --> "1" MyValue: value

@enduml

[pbazin]

Awesome it is! :)

[Dave Moten]

Support is added to version 0.1.19 on Maven Central now. I've also updated the online version at https://openapi-to-puml.davidmoten.org/prod/site/index.html. Plug this openapi yaml in there to see it work:

openapi: 3.0.1
info:
  title: unit test
  version: 0.0.1
components:
  schemas:
    Thing:
      properties:
        name: 
          type: string
        description:
          type: string
        property:
          type: object
          additionalProperties:
            $ref: "#/components/schemas/MyValue"
      required:
      - name
    MyValue:
      properties:
         name: 
           type: string
         expiry:
           type: string
           format: date-time
      required:
      - name
      - expiry

I didn't use the Struct type BTW, thought the composition marker was enough.

[Dave Moten]

0.1.19 produces;