We should move away from defining templates within the project itself towards a model where definitions can be provided by external sources. This should include the files/directories to be created, a schema file (JSON format?) defining the available parameters (including help messages, shortcut flags, type information).
I'm not set on a naming convention, but I am thinking that all templates/schematics (whatever we call them) would have names with a .template.<extension> syntax, i.e. my_resource.template.py that generates the my_resource.py using provided context parameters. The names of the files/directories must themselves be parameterized via the same mechanism as the code within them.
A very nice feature of Angular schematics that I would like here is a way for parameterization via function calls. This allows you to have a base name for a resource that gets reused in-kebob-format as well as lowerCamelCase or PascalCase where it makes sense. There are multiple ways to accomplish this same thing in Python, and I am not yet sure which is the best. Possibilities include:
Implement a DSL for separating the raw tokens from parameterized ones (e.g. like Angular does with some-constant- __name@dasherize__ to take the "name" parameter, convert it to kebob case, and then insert it after some-constant-). We could provide a fixed set of string operations, which is less extensible but also easy.
Use python-style template strings. This is probably the most direct way, but might have some other complications (storing parameterized templates that generate code that use template strings requires nesting of curly braces in ways that might be found cumbersome)
Don't provide this functionality, and instead rely on the user to provide multiple input parameters for the various versions of the names. This feels like a lazy copout
Overwriting existing files
If a template file is to be created that already exists on the actual file system, there should be a flag and/or interactive prompt to prevent accidentally stepping on existing files. This would be a flaskerize-level switch and not provided at the schematic level for obvious reasons (perhaps --force or --overwrite)
Ideation
We should move away from defining templates within the project itself towards a model where definitions can be provided by external sources. This should include the files/directories to be created, a schema file (JSON format?) defining the available parameters (including help messages, shortcut flags, type information).
I'm not set on a naming convention, but I am thinking that all templates/schematics (whatever we call them) would have names with a
.template.<extension>
syntax, i.e.my_resource.template.py
that generates themy_resource.py
using provided context parameters. The names of the files/directories must themselves be parameterized via the same mechanism as the code within them.A very nice feature of Angular schematics that I would like here is a way for parameterization via function calls. This allows you to have a base name for a resource that gets reused in-kebob-format as well as lowerCamelCase or PascalCase where it makes sense. There are multiple ways to accomplish this same thing in Python, and I am not yet sure which is the best. Possibilities include:
some-constant- __name@dasherize__
to take the "name" parameter, convert it to kebob case, and then insert it aftersome-constant-
). We could provide a fixed set of string operations, which is less extensible but also easy.Overwriting existing files
If a template file is to be created that already exists on the actual file system, there should be a flag and/or interactive prompt to prevent accidentally stepping on existing files. This would be a
flaskerize
-level switch and not provided at the schematic level for obvious reasons (perhaps--force
or--overwrite
)