Builder and stemapp. Custom widget workflows.

[LorenMueller]

I am using WAB Dev Ed 1.3 on Windows 8.1, node v4.2.3

Why does the Builder not allow the user to save changes to the stem app? Like if I want the stemapp to use a different map? I am able to view the stem app in the Builder at .../webappbuilder/?id=stemapp, but all of the save options are disabled. Is this by design?

{note: adding my own 'map' section to the stemapp config file did the trick, but why not allow this change in Builder?}

I would think the stem app would be the best place to work on custom widgets (not the setup and config processing perhaps, but the look/feel/functionality though) before spinning off apps with the new widget.

I suppose this begs the larger question... what are the workflows for development of custom widgets that folks are finding? It seems to me to that to stay sane with code management there should be a master copy of the widget that I am working on, say in client\stemapp\widgets\MyWidget\. But without changing the stemapp map I need to add the widget to an app that has access to the map and operational layers I am targeting to really use it. And adding it to an app forces it through its setup and config cycle which, if that is not what I am working on, is a bit annoying to go through. Is that what others are doing?

Summary:

1. Why, by design, can't I make changes via Builder to the stem app?

2. What development work flows are working best for you?

Thanks!

[RobertScheitlin__GISP]

Loren,

   The design of the stemapp is to be the unmodified base of all your apps (the use of stemapp was correlated to stem cells by the product designers). Though you can modify the stemapp manually if you have a coding change that you want reflected in ALL future apps you build using the builder. By design it is not intended for you to modify the stemapp using the builder UI.

The widget/theme development work flow I use for all my work is this.

1. Copy the [install dir]\client\stemapp\widgets\samplewidgets\CustomWidgetTemplate folder to the stemapp widget folder and rename it to your custom widgets name.
2. Open the manifest.json and change the name property to the exact name of the widget folder from step one.
3. I now work on changing the icon and some basics of the widget.
4. Now I create a new app (normally the app will be named the same as my custom widgets name)  and will see that my new custom widget is a choice in the widget choices.
5. Add my custom widget to the new app.
6. Now I do ALL my development in the [install dir]\server\apps\[app #]\widgets\my custom widget name folder.
7. Once I am done will my development I copy the widget folder back into the stemapp widgets folder so that new apps will use the completed widget code.

Hope this helps.

[LorenMueller]

Thanks for the reply Robert.

I will ll try your work flow out and see if I can keep my hands out of the guts of the stem app .

That is great info about your workflow. It sounds a lot like the use of a code repository doesn't it? The main or 'trunk' copy (stemapp/widget/MyWidget) and the development branches (app/#/widgets/MyWidget), and the push or merge back to the trunk. I am trying to think of the best workflow for applying a real code repo to the custom widget work that I will be doing in WAB Dev Ed, especially how multiple developers could share custom widget work on a single widget if need be. I suppose you could put the entire WAB Dev Ed folder into your repo  and all devs would be working from the same copy of WAB Dev Ed, which might be advantageous. If you ignored some files that store user specific info for connecting to AGOL or Portal that might work. Perhaps you have some thoughts on that or already use a repo for your work?

[RobertScheitlin__GISP]

Loren,

   I am a lone developer so I have not had to worry about that and I do not use a repo as you mentioned my workflow mimics a repo already in some ways.