Closed andy-berry-dev closed 9 years ago
Templates are also discussed here https://github.com/BladeRunnerJS/brjs/issues/3
Yeoman generators are used for scaffolding applications. You might - for instances - create a BRJS Yeoman generator that would understand BRJS templates, but also BRJS application structure.
In our case we just want templates as the application structure is defined by the BRJS model.
After a design discussion with @dchambers @james-shaw-turner and @ioanalianabalas we've decided on the following:
create-app
, create-bladeset
, create-blade
& create-library
will all accept an optionaly --template=<template>
arg that specifies the template to use--template
arg isnt provided the default will be usedconf/templates
and templates will be named <template-name>-<asset-container-type>
- e.g. angular-blade
, angular-bladeset
etc.@leggetter has suggested some changes to this plan (comments welcome):
/conf/templates/angular/blade
, /conf/templates/angular/bladeset
etc.--template=<repo-url>
Unless anyone has any objections it would seem sensible to include the first 2 of @leggetter's suggestions in the initial plan for template support.
@andyberry88 / @leggetter, I think:
is maybe a good idea, but shouldn't be something we do in the initial release.
Adding this would mean the getting started guide could be much more straightforward since the first command would be brjs create-app --template=github.com/repos/BladeRunnerJS/getting-started
rather than the user having to clone a repo or download a template into the right location themselves.
Since theres a Java Git client which makes this reasonably straightforward to achieve IMO we should do it for 1.0
I agree 3
should be pushed back until post 1.0.
Why not include a getting-started
template in the BRJS release, and then it becomes even simpler:
brjs create-app --template=getting-started
@dchambers, @james-shaw-turner and I had a further discussion on how we handle implicitly called user-templates (e.g. default aspect and default bladeset are created implicitly by the 'populate' method in app) if the user wants to use a template that has only been defined for the up-most level (e.g. app in this case). We have talked about 3 ways in which to handle this issue:
We have decided on option 3 for now, and we'll see in the future if there is a requirement to change this.
Adding new acceptance criteria as per the 02/12/2014 stand-up with @andyberry88, @dchambers, @leggetter, @thecapdan:
Please see #1109.
Started testing this. In general it seems fine but I have found an issue:
When I created a template to override the default aliases file in a blades resources folder. When I create a new bladevia the command line with the template flag:
danielo@SPARE-T440P /d/repo/brjs/brjs-sdk/workspace/sdk (user-templates-126)
$ brjs create-blade brjstomoo tomo boss --template=yikes
Successfully created new blade 'boss'
D:\repo\brjs\brjs-sdk\workspace\apps\brjstomoo\tomo-bladeset\blades\boss
It does indeed use the template i defined for the aliases file. However it fails to populate any of the other folders. (boss blade using new aliases template, hogg blade uses default)
I would expect that if it cannot find a template specified for the template attribute, then it should revert to the default templates.
@thecapdan, this is by design. I think @ioanalianabalas was maintaining a set of acceptance criteria somewhere, but can't seem to locate them.
Ok, I accept that my issue described above was not how this was intended to work. Which is fine.... IF -there is a way for me to satisfy my usecase:)
I would expect - if i create a 'default' folder in the templates folder, then any templates that I create in there should override the default template from the sdk, but revert to the sdk versions if they have not been defined in conf.
@ioanalianabalas can you point me at the acceptance criteria that was defined during previous discussions.
This is what was agreed upon during the design meeting on 11/12/2014:
Thanks @ioanalianabalas
So point 2 satisfies my usecase and i've tested to confirm it works. Can confirm points 1-7 works. Tested all using a user defined template for the aliases.xml in the blade.
Will merge once the conflicts are sorted
merged
Create a mechanism (similar to http://yeoman.io/) so devs can write their own templates and users can select which template to use for a new app/blade etc
For the first pass we don't need to create anything too clever. Pointing at a template directory or URL should be fine. The logic capabilities of the template definitions should not be the subject of discussion for this first pass.
Maybe a full template is just a template app with all supported Asset Containers defined and each command (
create-app
,create-bladeset
,create-blade
,create-library
) just uses the appropriate one. I believe we already have a mechanism similar to this anyway.