Renamed tabs and upadated content

Renamed tabs and upadated content

Notes that changes were made from:
  * Change the Quality tab to Features
  * Remove qualitative number ("16/33") from the top of the Features tab
  * Remove the red x's from the Features tab
  * Change the Interfaces tab name to Related charms
  * Change the source tab to Code
  * The styling of the code on the hooks page is wrong and should be like the styling of code on readme pages

Along with changing the tab names I updated the urls but this will have implications for exisiting links. We can keep the urls the same but it might seem a bit strange for things like "Features" linking to a url with "#quality".

https://code.launchpad.net/~huwshimi/juju-gui/more-iom-changes/+merge/179630

(do not edit description out of merge proposal)

[huwshimi, 2013-08-12 06:26:01]

Please take a look.

[gary.poster, 2013-08-13 00:44:23]

LGTM.  Please feel free to land after addressing my concerns.

The branch I mention (lp:~gary/juju-gui/more-iom-changes/) also has a fly-by fix
to the summary page when there is a word that is too long.  Look at the Jenkins
charm summary tab before and after to see what I was aiming for.

I did not run tests after making my changes, but hopefully the text and CSS
changes won't require test changes beyond what you have already done.

Thank you!

Gary

https://codereview.appspot.com/12734043/diff/1/app/subapps/browser/templates/...
File app/subapps/browser/templates/browser_charm.handlebars (right):

https://codereview.appspot.com/12734043/diff/1/app/subapps/browser/templates/...
app/subapps/browser/templates/browser_charm.handlebars:54: <li><a
href="#bws-related-charms" class="bws-related-charms">Related charms</a></li>
These changes are good.  However, if you go to an old link (like
#bws-interfaces), not only does the link not take you to the proper tab, but the
data is hidden behind some kind of semi-transparent block.  I'd like you to
either implement a redirect of some sort, or at least a fix for the
semi-transparent block problem (and simply defaulting to the summary, as it does
now).

https://codereview.appspot.com/12734043/diff/1/app/subapps/browser/templates/...
app/subapps/browser/templates/browser_charm.handlebars:160: Interfaces determine
how this charm relates to other charms. A relationship between charms can only
be made if they share a common interface.
This text is mildly odd for a "Related Charms" tab, but I think it is OK.

https://codereview.appspot.com/12734043/diff/1/app/subapps/browser/templates/...
File app/subapps/browser/templates/browser_qa.handlebars (right):

https://codereview.appspot.com/12734043/diff/1/app/subapps/browser/templates/...
app/subapps/browser/templates/browser_qa.handlebars:5: This charm has scored
{{totalScore}} out of a maximum of {{totalAvailable}}
The text of this template needed to be changed a lot.  Please merge
lp:~gary/juju-gui/more-iom-changes/ and use it if it is OK with you.

[huwshimi, 2013-08-13 02:36:48]

Please take a look.

[huwshimi, 2013-08-13 02:40:42]

On 2013/08/13 00:44:23, gary.poster wrote:
> LGTM.  Please feel free to land after addressing my concerns.
> 
> The branch I mention (lp:~gary/juju-gui/more-iom-changes/) also has a fly-by
fix
> to the summary page when there is a word that is too long.  Look at the
Jenkins
> charm summary tab before and after to see what I was aiming for.
> 
> I did not run tests after making my changes, but hopefully the text and CSS
> changes won't require test changes beyond what you have already done.
> 
> Thank you!
> 
> Gary
> 
>
https://codereview.appspot.com/12734043/diff/1/app/subapps/browser/templates/...
> File app/subapps/browser/templates/browser_charm.handlebars (right):
> 
>
https://codereview.appspot.com/12734043/diff/1/app/subapps/browser/templates/...
> app/subapps/browser/templates/browser_charm.handlebars:54: <li><a
> href="#bws-related-charms" class="bws-related-charms">Related charms</a></li>
> These changes are good.  However, if you go to an old link (like
> #bws-interfaces), not only does the link not take you to the proper tab, but
the
> data is hidden behind some kind of semi-transparent block.  I'd like you to
> either implement a redirect of some sort, or at least a fix for the
> semi-transparent block problem (and simply defaulting to the summary, as it
does
> now).
> 
>
https://codereview.appspot.com/12734043/diff/1/app/subapps/browser/templates/...
> app/subapps/browser/templates/browser_charm.handlebars:160: Interfaces
determine
> how this charm relates to other charms. A relationship between charms can only
> be made if they share a common interface.
> This text is mildly odd for a "Related Charms" tab, but I think it is OK.
> 
>
https://codereview.appspot.com/12734043/diff/1/app/subapps/browser/templates/...
> File app/subapps/browser/templates/browser_qa.handlebars (right):
> 
>
https://codereview.appspot.com/12734043/diff/1/app/subapps/browser/templates/...
> app/subapps/browser/templates/browser_qa.handlebars:5: This charm has scored
> {{totalScore}} out of a maximum of {{totalAvailable}}
> The text of this template needed to be changed a lot.  Please merge
> lp:~gary/juju-gui/more-iom-changes/ and use it if it is OK with you.

Thanks Gary, I had to fix up the text wrapping a little bit (it was breaking the
text onto new lines) and I also added the redirects.

I wasn't entirely sure about what the best approach for implementing the
redirects was so would be good to have a review of that.

[rharding, 2013-08-13 11:08:04]

I'll take a look, but I bet the issue with the clicking an old link was that the
activeTab work isn't fail-safe. 

      if (this.get('activeTab')) {
        this.get('container').one(
            '.tabs a[href="' + this.get('activeTab') + '"]').get(
            'parentNode').simulate('click');
      }

I'll bet there was an exception thrown because there was no node to get the
parentNode and click on. This probably caused the loading overlay to never stop
or something. 

I'd rather we make this safe than add in complex redirect logic mapping the old
tabs to new. It seems like clutter for little gain. If we keep it, then we
should add tests for the new code we're supporting.