Skip to content
GitLab

Data object classes for templating context

Open Administrator requested to merge github/fork/rienafairefr/templating-input-base-object into master

Created by: rienafairefr

Sorry in advance for the massive PR, though I can't seem to see how it could be made with less

PR checklist

  • Read the contribution guidelines.
  • Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh and ./bin/security/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\.
  • Filed the PR against the correct branch: master, 3.3.x, 4.0.x. Default: master.
  • Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

@jimschubert @wing328

Description of the PR

in some discussion with @jimschubert here I've seen that the current plethora of Map<String, Object> pseudo-classes should be avoided. Indeed, it's making us do a lot of casting back and forth between Object and Map<String, Object>, a lot of unchecked casting warnings are suppressed, type safety is not used, overall it's something that could be changed for the better

I've implemented a bunch of data-only classes (suffixed Bundles for now but I could see using DTO or Bag if whatever terminology is preferred) for replacing all these Map<String, Object> that could be replaced. Of course we need to keep the vendorExtensions, additionalProperties maps, and probably others I'm forgetting of the top of my head, unchanged, because these really need to be truly dynamic (they can be changed by the spec or the user).

There is a bit of conundrum with the additionalProperties there because when executing a template, we want to pass it a context that can be a POJO, but we also want the values from additionalProperties to be available (e.g. {{licenseInfo}} or {{appDescription}}. I added a AdditionalPropertiesBundle base class to handle that, but it feels hacky to me: I convert the POJO to a map, and add the additionalproperties to it, just before it goes into the template.execute(context...), it needs a better solution I think.