Enabled browser to be enabled by default via FF

Enabled browser to be enabled by default via FF

- Add the idea of the browser_enabled feature flag.
- Only add the browser subapp to the list of subApplications if the FF is
present
- Pulled the existing branch of code that enables the browser to operate by
default.
- Updated the tests so that the flag is enabled when checking the subapp is
loaded correctly.

MP Notes from original browser default MP:

- Remove the /bws/ prefix on the routes and all instances of it.
- Add a new route for / and /*charmid
- Add a couple of tests to verify the new routes will route correctly,
defaulting to the sidebar view
- Update the browser app and the Charmworld0 store api handler to allow for a
nop since not all tests will want to setup a fake store api endpoint. Since
the browser is always visible, it wants to try to always load editorial
content. The nop allows it to carry on but will hit the apifailure call so
that it should not silently hide failures.


Notes:
- Using the dot notation for feature flags in JS is confusing. I initially
wanted to create an nested object for the browser subapp space of flags. I
changed this to _ in the docs and used browser_enabled so that the JS code can
read simpler as just window.flags.browser_enabled vs using a combination of
object/array-like notation.
- There was an update required to allow setting the feature flags in the
juju_config. That's not the same as GlobalConfig. Mistake in the previous
branch.

Known issues:
- This only deals with enabling the browser to get away from the url /bws
namespace and to feature flag it. Other known bugs still exist. In particular,
in QA'ing you'll run across the black bar at the top of the UI for pages with
the tabview on it. This will be updated in a follow up branch.

QA:
- To QA, pull this branch down and hit the app with the flag enabled:
/:flags:/browser_enabled

https://code.launchpad.net/~rharding/juju-gui/flag-browser/+merge/166048

(do not edit description out of merge proposal)

[rharding, 2013-05-28 13:32:42]

Please take a look.

[hatch, 2013-05-28 14:14:51]

LGTM - With a few changes

See the trivial comments below. 

We now have a document to track odd testing `gotchas` in docs/unit-testing.rst
could you add some notes in there about the new noop functionality for the
charms.

https://codereview.appspot.com/9731047/diff/1/app/subapps/browser/browser.js
File app/subapps/browser/browser.js (right):

https://codereview.appspot.com/9731047/diff/1/app/subapps/browser/browser.js#...
app/subapps/browser/browser.js:203: /*jslint bitwise: true*/
I think you have to set this back to it's default else it will have this setting
for the remainder of the parsing.

https://codereview.appspot.com/9731047/diff/1/app/subapps/browser/browser.js#...
app/subapps/browser/browser.js:687: if (!window.juju_config || !
window.juju_config.charmworldURL) {
no space between ! and window

https://codereview.appspot.com/9731047/diff/1/test/test_browser_app.js
File test/test_browser_app.js (right):

https://codereview.appspot.com/9731047/diff/1/test/test_browser_app.js#newcod...
test/test_browser_app.js:319: it('viewmodes we not a valid charm id', function()
{
typo?

[j.c.sackett, 2013-05-28 14:16:00]

https://codereview.appspot.com/9731047/diff/1/app/subapps/browser/views/charm.js
File app/subapps/browser/views/charm.js (right):

https://codereview.appspot.com/9731047/diff/1/app/subapps/browser/views/charm...
app/subapps/browser/views/charm.js:67: }
Should we update style on these to make sure they're not shown as links to the
user, then? Or is that already the case?

[j.c.sackett, 2013-05-28 14:16:23]

Previous comment is an LGTM; just a thought on the styling.

[rharding, 2013-05-28 14:21:56]

Please take a look.

[rharding, 2013-05-28 14:22:31]

Updated per comments and replies below.

https://codereview.appspot.com/9731047/diff/1/app/subapps/browser/views/charm.js
File app/subapps/browser/views/charm.js (right):

https://codereview.appspot.com/9731047/diff/1/app/subapps/browser/views/charm...
app/subapps/browser/views/charm.js:67: }
On 2013/05/28 14:16:00, j.c.sackett wrote:
> Should we update style on these to make sure they're not shown as links to the
> user, then? Or is that already the case?

These are the tabs themselves. They're styled to be clickable, but the Y.App
should not think any navigation change has occurred and try to re-process the
update url that tabview widget puts out.

[j.c.sackett, 2013-05-28 14:23:16]

On 2013/05/28 14:22:31, rharding wrote:
> Updated per comments and replies below.
> 
>
https://codereview.appspot.com/9731047/diff/1/app/subapps/browser/views/charm.js
> File app/subapps/browser/views/charm.js (right):
> 
>
https://codereview.appspot.com/9731047/diff/1/app/subapps/browser/views/charm...
> app/subapps/browser/views/charm.js:67: }
> On 2013/05/28 14:16:00, j.c.sackett wrote:
> > Should we update style on these to make sure they're not shown as links to
the
> > user, then? Or is that already the case?
> 
> These are the tabs themselves. They're styled to be clickable, but the Y.App
> should not think any navigation change has occurred and try to re-process the
> update url that tabview widget puts out.

Ah, dig. Thanks for the clarification.

LGTM, as I said.

[rharding, 2013-05-28 15:03:27]

*** Submitted:

Enabled browser to be enabled by default via FF

- Add the idea of the browser_enabled feature flag.
- Only add the browser subapp to the list of subApplications if the FF is
present
- Pulled the existing branch of code that enables the browser to operate by
default.
- Updated the tests so that the flag is enabled when checking the subapp is
loaded correctly.

MP Notes from original browser default MP:

- Remove the /bws/ prefix on the routes and all instances of it.
- Add a new route for / and /*charmid
- Add a couple of tests to verify the new routes will route correctly,
defaulting to the sidebar view
- Update the browser app and the Charmworld0 store api handler to allow for a
nop since not all tests will want to setup a fake store api endpoint. Since
the browser is always visible, it wants to try to always load editorial
content. The nop allows it to carry on but will hit the apifailure call so
that it should not silently hide failures.


Notes:
- Using the dot notation for feature flags in JS is confusing. I initially
wanted to create an nested object for the browser subapp space of flags. I
changed this to _ in the docs and used browser_enabled so that the JS code can
read simpler as just window.flags.browser_enabled vs using a combination of
object/array-like notation.
- There was an update required to allow setting the feature flags in the
juju_config. That's not the same as GlobalConfig. Mistake in the previous
branch.

Known issues:
- This only deals with enabling the browser to get away from the url /bws
namespace and to feature flag it. Other known bugs still exist. In particular,
in QA'ing you'll run across the black bar at the top of the UI for pages with
the tabview on it. This will be updated in a follow up branch.

QA:
- To QA, pull this branch down and hit the app with the flag enabled:
/:flags:/browser_enabled

R=hatch, j.c.sackett
CC=
https://codereview.appspot.com/9731047