Discussion, Enhancement: customisation of generated structure through templating

Created by: rienafairefr

I've been thinking about some discussion/PR/issues (e.g. #470, #586, PR #580, #591 ), or others, and I felt that right now when you want to customise anything about the generated code that doesn't fit into the directory structure that have been defined in the java *Codegen class, you're stuck.

The tool allow people to specify a template directory to customise the output of the tool, by changing the templates. Why not allow them to modify the directory structure by also specifying a template ? I've pushed a PR to show a bit what I mean ( see #619)

Right now, the folder where models are generated, the folder where model docs/model tests, the location of the supporting Files, all of this is defined in Java. But with this, if there is a structure.mustache template, then the structure is defined by the folders/files hierarchy defined in the result of that template. Right now the example implementation assumes that the structure.mustache generates a YAML file, but that's not mandatory.

For example, in order to add a supportingFile to the output, you can either do

supportingFiles.add(new SupportingFile("tox.mustache", "", "tox.ini"));

in the java *Codegen code, or you can have your structure.mustache be like

supportingFiles:
  tox.ini: tox.mustache

This way, it's painless (no java code modification) if you want to put a certain supporting file somewhere else, example

supportingFiles:
  common_package:
    __init__.py: __init__package.mustache
      client.py: api_client.mustache

if you want to generate the common (a file that doesnt depend on the spec) package in a certain subfolder of your output folder

Positive points

• We can reuse the templating knowledge to customise the directory structure itself
• In time, we can remove a bunch of methods in CodegenConfig that force a certain directory structure
• backward compatibility (if there is no structure.mustache template then the generation is unchanged)

Negative points

• Specifying model and api files (i.e. generate a bunch of files for each api or each model, docs for each, tests for each, etc) is not really intuitive in that model (the filename is the suffix for the file, the name of the file is still decided by the config.toModelFilename( and similar methods Maybe a template in a template ?

apis:
  {{ packageName }}:
    api:
{{=<% %>=}}
      {{ apiFilename }}.py: api.mustache
<%={{ }}=%>