lp:~makyo/juju-gui/clear-state-refactor

Created by Madison Scott-Clary and last modified
Get this branch:
bzr branch lp:~makyo/juju-gui/clear-state-refactor
Only Madison Scott-Clary can upload to this branch. If you are Madison Scott-Clary please log in for upload directions.

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
Madison Scott-Clary
Project:
juju-gui
Status:
Development

Recent revisions

207. By Madison Scott-Clary

Cancel view state

206. By Gary Poster

change charm store data structures

This change is hopefully the last round of changes, at least for a long while, to the underlying charm store infrastructure. It is more deletes than additions, and changes the code to take advantage of the changes Kapil made to the charm store.

The sorting code is simplified yet again.

R=benjamin.saller
CC=
https://codereview.appspot.com/6733067

205. By Madison Scott-Clary

Render menus more intelligently

Menus are rendered to the right or left of the service node depending on which side of the environment view they are on, and the menus track better with scrolling (around the arrow rather than around the top of the menu).

R=benjamin.saller
CC=
https://codereview.appspot.com/6766052

204. By Madison Scott-Clary

Ambiguous relation improvements

Ambiguous relations sorted in menu; relations aren't indented; cancel button says 'Cancel' and is styled; click to add relation is fixed; pending relation line shown with click to add relation, and lingers when menu is open.

R=benjamin.saller
CC=
https://codereview.appspot.com/6765050

203. By Gary Poster

Reinstate charm tooltips

The fix I made in the previous branch was incorrect. This branch reinstates the charm configuration tooltips.

202. By Gary Poster

Quick fix for silent error with charm tip

Matt reported that a silent error was thrown if you used the scrollwheel in the charm store config page before tabbing to a field. This is a quick fix that I plan to self-approve.

201. By Brad Crittenden

Charm config panel visual design

First pass at getting the visual design. This branch begins using
some of the specified assets.

The placement of the buttons and cogs feels crude. I'm happy to get
suggestions on better ways to do the CSS for those elements.

Note replacing the pop-up was not in the scope of this branch. The
elements below the buttons are being left for another branch in order
to get earlier feedback on the approach.

R=gary.poster
CC=
https://codereview.appspot.com/6709062

200. By Thiago Veronezi

Service view header gui design (pre-approved)

This code is already approved by https://codereview.appspot.com/6724059/
I needed to propose it again because the old trunk is dead and the previous
proposal was pointing to it.

R=
CC=
https://codereview.appspot.com/6741058

199. By Madison Scott-Clary

Implement ambiguous relation menu for adding rels

Displays a menu of choices when adding a relation between two services would result in ambiguity, otherwise simply adds a relation. Also, a bit of minor test clean-up in charm config, due to floating point inequality.

R=thiago, benjamin.saller, hazmat
CC=
https://codereview.appspot.com/6736051

198. By Gary Poster

Separate environment and store charms

On discussion with Kapil, a significant problem from a previous refactoring of mine became clear. Charm ids are only reliably unique within a given context, such as juju environment vs charm store. Therefore, charms from the two sources need to be stored separately.

We discussed some approaches. He suggested storing environment charms in the database and store charms in the browser, and I liked that idea. He also requested that I factor out the charm model code into a separate file, even while keeping it in the juju.models package. Finally, he suggested that charm ids should always include revisions in order to guarantee uniqueness, and to make it possible to consider whether charms from the different sources are identical.

I wrote a long explanation of this in the app/models/charms.js file, including additional considerations.

The charm store needed to send the revision itself, which Kapil changed it to do.

I ended up also factoring out a charm store object, with the ability to get the data from a search, organized as we like it; and to get the data for a specific charm. A nice fall out from the tests of this code is that it exposed some pre-existing problems with sorting code, which I addressed.

The change is quite large because it touches so many of the files. On the bright side, many of the test changes are mechanical, and much of the code is moved and only slightly refactored and changed from other sources, so deletions and moves account for much of the churn.

Kapil made some great changes to the charm store after reviewing this branch that will let us simplify this branch's code in a follow on.

R=hazmat
CC=
https://codereview.appspot.com/6749046

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
Stacked on:
lp:juju-gui/experimental
This branch contains Public information 
Everyone can see this information.