Skip to content
This repository has been archived by the owner on May 23, 2022. It is now read-only.

3D widget template #50

Closed
wants to merge 8 commits into from
Closed

3D widget template #50

wants to merge 8 commits into from

Conversation

jPurush
Copy link
Contributor

@jPurush jPurush commented Feb 10, 2016

I've verified(manually, not via generator) the template to work in 2.0Beta, need to however do the following:

  1. App Path prompt is set to 1.3 WAB
  2. support for stemapp3d in App Directories
  3. Tests
  4. Doc

Also, if this is going to be post release of generator 2.0, maybe there is a way that doesn't need a separate 3D manifest.json file.

tomwayson and others added 7 commits February 9, 2016 08:12
updated package.json dependencies to match latest generator-generator
output

minor changes to generator files
- a few formating chagnes for new ejs template engine
- importing yeoman.generator.Base directly

major overhaul to test files
- directly requiring/using yeoman-assert
- using helper.run().inTmpDir()
- using mkdrip instead of mkdir
- removed load test
- using before() instead of beforeAll() for all widget generator tests
updated to latest yeoman-generator (0.22)
name: '3D'
}
]
},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it valid to have a widget that is both 2d and 3d? Either way, we should add a validator to this prompt that ensures that at least one is checked, and possibly not allow both to be checked (in case that is not valid)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Initial research indicates that we should be scaffolding one or the other (2d or 3d), so this should become a radio button prompt. Maybe one day the WAB will support the idea of a single widget that can work in both 2d and 3d, but for now, you can see that most, if not all, of the OOTB widgets have separate 2d and 3d versions.

@tomwayson
Copy link
Member

Thanks for this @jPurush! A good start. Raises a lot of questions.

Here are some responses to the TODOs you list above

App Path prompt is set to 1.3 WAB

I think we'd leave the default to 1.3 until WAB 2.0 is out of beta. This raises the question, what if someone enters the path to a WAB 1.3 install while running the default generator and then tries to generate a 3d widget. Are we going to try and detect WAB capabilities at any point to prevent that, or just let that happen?

support for stemapp3d in App Directories

Oh man, a whole new stemapp folder. Makes sense, but that's going to impact the default generator too. How is it going to know which stemapp folder to copy a given widget to (if, for example, you had a project folder w/ both 2d and 3d widgets)?

Tests

Currently failing (need to add a 2d/3d response to the prompts passed in widget tests). Before trying to get them to pass however, this branch should be merged w/ current master (after #48). That should make it easier.

Also see my questions in the line comments.

All in all, I need to understand better how WAB 2.0beta works before I can answer any of these. I'm going to start on #45 so that I can get some insight.

However all of this is making me realize that adding support for 3d is non-trivial, may introduce breaking changes, and should probably be included in the v2.0 release.

cc @gavinr

@tomwayson
Copy link
Member

After talking w/ @gavinr, came up w/ the following:

  • default generator will prompt for 2d/3d, and configure the grunt task to write to the correct folder (stemapp or stempapp3d). The response to this could probably dictated the default path to the WAB
  • any subsequent runs of the widget subgenerator will get the 2d/3d setting saved from the default generator

I'll break the above out into issues in the next few days. I just wanted to document the decisions here for now. Once the issues are up we can decide if we'll continue to work on this branch (since it's a whole new direction).

@tomwayson
Copy link
Member

closed in favor of #54

Thanks @jPurush

@tomwayson tomwayson closed this Feb 29, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants