clux
commented
12 years ago I think that while the build process could be useful to separate from the main server, by using plugins, you are tying it very much down to variables and domains present on the server. Thus, doing the build outside of that environment only makes sense if you have found a way to export all that data, behaviour somewhere else.
This isn't a problem, and if you want to go this far, then calling the programmatic API inside a Cakefile, for instance, is a much better and more configurable solution. Will include a simple example for this as well for the next version.
EDIT: As for the actual CLI interface to plugins, I will stick to the simplified first solution.
Difficult to decide on. It has to be simple enough to use nicely in the CLI, yet advanced enough to be fully configurable in case of a big plugin.
In current master: Plugins all take ordered constructor arguments coerced from strings to be able to be inputable via -g pluginName:[arg1,arg2,...]. PRO: very easy to write PRO: for simple plugins, this is the easiest. CON: if plugins take a lot of dependent arguments down the line, it gets crazy.
Alternatively, Plugins could be configurable from a json file.
PRO: Reading input from a config file could be done via a base class that all plugins must extend. PRO: In case more is needed later, easy to extend then. PRO: Gain named parameters CON: Can't serialize that much better than what we can already CON: Have to deal with several config files for plugins when using the CLI.
/me has a think