Allow overriding interpreters

[artur-ciocanu]

Reason/Context

Today modelina allows different customizations via preset mechanism. It works great for most of the cases, however there are situations when customizing the code generator output is impossible, because of some of the hard-coded logic that can be found in processors and interpreter. For example, if we want to customize the output of the schema field that have additionalProperties, then we really have no choice, but to accept that any field that looks like this:

{
  "$schema": "http://json-schema.org/draft-06/schema#",
  "title": "Test",
  "type": "object",
  "properties": {
    "prop": {
      "type": "object",
      "additionalProperties": false
    }
  },
  "additionalProperties": false,
  "required": [
    "id"
  ]
}

Will be translated into something like this (e.g. Java code gen):

public class Test {
  private Prop prop;

  public Prop getProp() { return this.prop; }
  public void setProp(Prop prop) { this.prop = prop; }
}

public class Prop {
  
}

Which is quite unfortunate since we can do anything useful with this Java class. I would argue that the above schema declaration should generate something like this:

public class Test {
  private Object prop;

  @JsonProperty("prop")
  public Object getProp() { return this.prop; }
  public void setProp(Object prop) { this.prop = prop; }
}

I would like to mention that if we use a schema like this:

{
  "$schema": "http://json-schema.org/draft-06/schema#",
  "title": "Test",
  "type": "object",
  "properties": {
    "prop": true
  },
  "additionalProperties": false,
  "required": [
    "id"
  ]
}

Or

{
  "$schema": "http://json-schema.org/draft-06/schema#",
  "title": "Test",
  "type": "object",
  "properties": {
    "prop": {
       "title": "Prop"
    }
  },
  "additionalProperties": false,
  "required": [
    "id"
  ]
}

Then we get a property of type Object. As far as I can tell all the 3 schema definitions are equivalent from code generation perspective, however since InterpretAdditionalProperties can't be customized we can't do anything about it.

Description

One possible solution is to allow clients to pass custom interpreters for all the different properties like oneOf, anyOf, additionalItems, additionalProperties, etc. This is somewhat similar to the way we can create custom presets and add them via config.

[artur-ciocanu]

This issue is related to this discussion: https://github.com/asyncapi/modelina/discussions/870.

[handrews]

Using JSON Schema to interpret/disambiguate JSON Schema validation constructs for effective (and flexible code generator usage is a major focus of the IDL JSON Schema Vocabulary project.

[jonaslagoni]

One possible solution is to allow clients to pass custom interpreters for all the different properties like oneOf, anyOf, additionalItems, additionalProperties, etc. This is somewhat similar to the way we can create custom presets and add them via config.

I would highly recommend doing this in stages, with one PR for each interpreter function. Makes it easier to introduce tests, the code, and review it 🙂

[artur-ciocanu]

One possible solution is to allow clients to pass custom interpreters for all the different properties like oneOf, anyOf, additionalItems, additionalProperties, etc. This is somewhat similar to the way we can create custom presets and add them via config.

I would highly recommend doing this in stages, with one PR for each interpreter function. Makes it easier to introduce tests, the code, and review it 🙂

@jonaslagoni I have just started exploring, how I should approach it. The plan is to prepare all the "infra" like passing processOptions to processors and other minor changes like this. Before I get to the "meat" of the problem. I'll send separate PRs to make it easier for everyone to review and provide feedback.

Stay tuned ... 😄

[jonaslagoni]

@artur-ciocanu let me know if you need anything from me 🙂

[artur-ciocanu]

@jonaslagoni thanks for checking, I was a little busy I'll try to get back to this and let you know if I am blocked.

[artur-ciocanu]

@jonaslagoni I have tried the latest next build 1.0.0-next.36 and it seems that the interpreter customization is not required, at least for now.

I will close the issue and if we will ever need this customization I will open another issue.

Sorry that it took me so long to verify everything.

[jonaslagoni]

@artur-ciocanu I thought the idea was that you could provide your own extension of the interpretation functionality so you could do something like:

const options = {
  interpreter: {
    interpretAllOf: () => { //Custom functionality for interpreting allOf }
  }
};

Or was this not want you meant? 🙂

[jonaslagoni]

Gonna close this issue @artur-ciocanu as we solved your issue with providing simple interpreter options to enable and disable additionalProperties and additionalItems.

Feel free to re-open if this feature comes to mind again, or if others respond 🙂