Allow subtemplates to be reached out from anywhere

[aalmiray]

Here's the use case I've for this feature request: a griffon-plugin template initializes a typical Griffon project. This project may provide common artifacts such as controllers and services. These artifacts should be initialized using any of the standard artifact subtemplates available in the application projects. The key concept here is that each application project provides UI toolkit/language specific templates such as swing-java, javafx-groovy and so forth. Duplicating all toolkit/language artifact combinations for the griffon-plugin template is overkill.

What if lazybones allowed something like this:

lazybones generate --parent=griffon-swing-java artifact::controller

Both --parent and --version (in the case of locally installed templates) should be taken into account. The current behavior of generate should be unaffected if --parent is not specified.

[pledbrook]

So you're saying that a new project could include artifacts based on swing-java, javafx-groovy, and more? If I understand correctly, I'm thinking it might be better to have an alternative template installation option:

lazybones create griffon-swing-java --sub-templates-only "."

Or perhaps a separate command:

 lazybones sub-templates griffon-swing-java 1.0.0

Once the sub-templates are installed into the local project, generate can access them. The downside to this is potential conficts between sub-template names. So I guess --parent would still be needed.

I'm not currently a huge fan of this idea because it feels like a workaround to lack of template dependencies. It's also pretty tedious for the user to specify the parent every time. Need to think on this.

[aalmiray]

Correct, there may be a name clash between subtemplates. In the case of Griffon application templates this is a guaranteed scenario as all of them include their own version of the artifact template; thus no matter which template you used to create the project you can always invoke

lazybones generate artifact::view

and get an appropriate View class given the specific toolkit/language combination of the parent project. You could think that unpacking the templates will work and you're right, for most cases this would be a solution, buuut a griffon plugin may be a multi-project that contains various subprojects, each one targeting a specific toolkit. This is true for the scaffolding plugin that contains both swing and javafx subprojects sigh.

I agree on the lack of template dependencies however in this case I don't think having to specify --parentevery single time is really a downside.

[pledbrook]

I think #142 is a rephrasing of this requirement. I can definitely see the value.

[aalmiray]

Hmm yes #142 sounds better though, so closing this one.