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
<%={{ }}=%>