Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support more complex/branching logic in template manifest files #360

Open
kmahar opened this issue May 18, 2021 · 2 comments
Open

Support more complex/branching logic in template manifest files #360

kmahar opened this issue May 18, 2021 · 2 comments
Labels
enhancement New feature or request

Comments

@kmahar
Copy link

kmahar commented May 18, 2021

Is your feature request related to a problem? Please describe.

I was looking into expanding the default API template some to incorporate support for using a database without Fluent via a provider library, like mongodb/mongodb-vapor which I maintain, or vapor/redis.

I was envisioning that, if a user said no to using Fluent, we could then ask them if they wanted to use a database without Fluent.

However, I ran into a bit of a problem in that as far as I can tell the manifest spec format does not have much support for branching logic, as in there doesn't seem to be a way to ask the user for input only when they replied no to a previous question. Apologies if this is actually possible, but I couldn't figure out a way to express it based on looking at TemplateScaffolder.swift.

As a result, I think my proposed new question would make it hard to provide a clear flow of questions for users who do want to use Fluent. Even if they said yes to Fluent and picked a DB, they would then have to answer a potentially confusing next question about using a DB without Fluent.

Describe the solution you'd like
A way to branch on the value of a previously supplied variable in a manifest.

For now I am just making my own template that assumes one is using mongodb-vapor to handle my use case since it simplifies things. But it would be cool to expand the expected manifest format, to both enable making the default template more featureful and also expand the capabilities for anyone developing custom templates.

The first idea that comes to mind is that maybe variables could support supplying some kind of a conditional that determines whether to ask the user for them, but I'm sure there are a number of other ways you could accomplish this which might be more general solutions.

Describe alternatives you've considered

Additional context
If this is indeed not supported yet and is of interest to add, I can try take a crack at implementing it assuming we can reach some consensus as to what the format expansions should look like.

@kmahar kmahar added the enhancement New feature or request label May 18, 2021
@0xTim
Copy link
Member

0xTim commented May 19, 2021

Looking at it you're right there doesn't seem to be anyway to offer another option on a no input. If you're up for it a PR to improve the behaviour would be awesome!

Another option would be to invert the questions and start with "Would you like to use a database", then choose the database option and then choose Fluent if it makes sense for that DB.

@kmahar
Copy link
Author

kmahar commented May 19, 2021

If you're up for it a PR to improve the behaviour would be awesome!

Yeah, I can try to put something together!

Another option would be to invert the questions and start with "Would you like to use a database", then choose the database option and then choose Fluent if it makes sense for that DB.

I thought about this one a bit, where we could repeat the Fluent/no Fluent question under each relevant DB, but I couldn't figure out how to nest a boolean variable under an option as of now. Any idea how to? 🤔
It does seem like support for doing that would be a way to achieve this, though it might be tricky to do without introducing some backwards-breaking changes to the existing CLI, since currently something likevapor new MyProject --fluent.db=Postgres works, and if the questions change I assume the generated CLI options might be different... Though, I suppose support for customization of the CLI options might be able to solve that. (Also not sure if you consider the CLI options on the default template to be semver protected?)

Another option I thought of would be to just flatten the list and have a single "which database" question choices like "Postgres with Fluent, MongoDB with Fluent, MongoDB without Fluent, Redis", etc. However, that seems like it would also lead to breaking CLI option changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants