Code generation proposal

[ghost]

Right now harness is used for auto generation of files for Reverse routing, etc. This is a proposal to replace harness by small independent utilities that will be run by go generate.

[brendensoares]

👍 Love this. Let's discuss at our next meeting!

[brendensoares]

@AnonX could we add a built-in revel install command that downloads and installs a default set of revgen commands?

[ghost]

@brendensoares I know unix way, one program = one function, and stuff like that. But what if we have the following packages right in our revel/cmd:

• runner - parse .revel.yml (described in data migrations revel#889 (comment)) and execute commands.
• handlers - generate handlers from controllers.
• routes - generate router from handlers and app/routes file.
• help - show help message about supported options.
• main.go - as simple as switch { case: ... } that runs the packages mentioned above.

That will let us avoid polluting user's PATH. That's especially important taking into account the fact that revgen-controllers is not intended to be run by user (go generate is what responsible for that).
Architecture still will be modular and simple. Users will be able to write their own generators if they want. And we won't have to introduce revel install.

Just like go has: build, clean, env, fix, fmt, generate, get, install, list, run, test, tool, version, vet, revel will have: run, generate handlers, generate routers, generate validators, help.

[ghost]

I'm not a Shakespeare and my writings are not as good as I wished. But I think that is exactly what I meant by:

It is possible to implement all those programs as separate packages and use revel generate cmdName command as a wrapper

[brendensoares]

@AnonX I would much prefer to have them compiled in to revel/cmd. I think we're on the same page now. We won't have separate binaries, but we will have modular code that implements a common interface. This is what we essentially do now with revel/cmd, but we can extend it further and standardize it.

[brendensoares]

Months later...I have to wonder if we should care about making generate commands manageable at runtime and not just compile time?

[ghost]

@brendensoares I've been working on my own implementation of toolkit that is based on ideas of this PR + revel/revel/issues/889 + revel/revel/issues/420 + modified definition of:

• controller - any structure that has actions;
• action - any method that returns action.Result interface as the first result.

Here is what I've got: https://github.com/alkout/goal (still in PoC stage).
For illustration of what I meant...

[brendensoares]

@AnonX before and after is something I still really want myself. I'm interested to see how you go about the task runner functionality.

Glad you've been experimenting with your ideas. Sorry I disappeared.