Consider template hierarchies as a way to scale to more templates

[pq]

The basic idea would be to group templates under categories (web, console, etc) and then provide variations underneath. For example:

web-basic
web-polymer
console-basic
console-package
...

If a variation isn't specified the minimal/basic template is defaulted to.

IDEs could show these groupings hierarchically (e.g., in a tree):

web/
basic
polymer
...
console/
basic
...

(Or not.)

[devoncarew]

+1, I think grouping the templates into categories will help the users digest the templates we have available, and more easily choose between two templates in a category.

[damondouglas]

I started implementing #167. Am I moving in the right direction? I changed cli_app.dart and stagehand.dart to utilize args.Command's subcommand capabilities. The following shows resulting usage outputs:

$ dart bin/stagehand.dart 
Stagehand will generate the given application type into the current directory.

Usage: stagehand <command> [arguments]

Global options:
-h, --help              Print this usage information.
    --[no-]analytics    Opt-out of anonymous usage and crash reporting.
    --version           Display the version for stagehand.
    --author            The author name to use for file headers.
                        (defaults to "<your name>")

Available commands:
  client   Generate web application types.
  help     Display help information for stagehand.
  pub      Generate pub library types.
  server   Generate server application types.

Run "stagehand help <command>" for more information about a command.

$ dart bin/stagehand.dart client
Generate web application types.

Usage: stagehand client <subcommand> [arguments]
-h, --help    Print this usage information.

Available subcommands:
  polymerapp         A web app built using polymer.dart.
  ubersimplewebapp   An absolute bare-bones web app.
  webapp             A mobile-friendly web app with routing, responsive CSS, and (optional) Sass support.

Run "stagehand help" to see global options.

$ dart bin/stagehand.dart pub
Generate pub library types.

Usage: stagehand pub <subcommand> [arguments]
-h, --help    Print this usage information.

Available subcommands:
  package   A starting point for Dart libraries or applications.

Run "stagehand help" to see global options.

$ dart bin/stagehand.dart server
Generate server application types.

Usage: stagehand server <subcommand> [arguments]
-h, --help    Print this usage information.

Available subcommands:
  appengineapp   A simple AppEngine application.
  consoleapp     A simple command-line application.
  shelfserver    A web server built using the shelf package.

Run "stagehand help" to see global options.

[devoncarew]

Hey Damon, sorry for the delay and thanks for reaching out. This is slightly different than I was thinking. I was envisioning still having one id for an app type, but that the id would help categorize apps. So, web-basic and web-polymer, and the web prefix helps users know what the app type is, and lexically sorting them helps keep related ones together. Supporting sub-commands would be another way, but I think I prefer the simplicity of having the type encoded into the id. But thanks for doing some thinking about this!

[devoncarew]

Related discussion over here: https://github.com/google/stagehand/issues/192.

[damondouglas]

Thank you @devoncarew for your helpful feedback. I will look for other ways to help where I can.

[devoncarew]

Done - the new template id's are:

`console-full`
`package-simple`
`server-appengine`
`server-shelf`
`web-full`
`web-polymer`
`web-simple`

[sethladd]

+1