dmgress / cloudgrapher Goto Github PK

The switch to cytoscape 2.5 caused some changes in provided layout extensions and how to include new ones. I had to remove:

• Arbor
• Cola
• Dagre
• Spread

Maybe they're still useful? Or perhaps some others are nice too?

The buttons in the button bar don't have titles or tooltips when you hover over them. Adding a title attribute to each list item will fix this.

When an invalid template is loaded the graph area should:

• clear any previous graph
• indicate the template is invalid

The current setup of a single static page has several limitations. By switching the codebase to a Node application it will be possible to proxy through it's own back-end and use non-browser capabilities through API calls in the future.

After switching to grid layout and editing the template, the graph gets redrawn with the cose layout.

The preferred option is to use the currently selected layout, the alternative to update the layout selector.

The template dependents on .getDoc, which is too much detail. It shouldn't have to know more than a simple get and set of the current value.

When the template has been modified in the editor and the user leaves or loads another template, then a confirmation dialog becomes visible

• able to detect changed template
• shows modal confirmation dialog
• prevents exit until confirmation dialog closes
• prevents template change until confirmation dialog closes

• Sign in with AWS (temporary) credentials
• Retrieve list of stacks
• Load selected stack into editor

It should be possible to embed a generated graph through the use of several query parameters. The parameter embed indicates it should only show a cytoscape graph or rendered png image.

By default it will use a predefined graph type, style and dimension.

Parameters required for:

• graph type
• cloudgrapher style (see issue #8)
• custom cytoscape CSS URL
• show style menu
• dimensions (width & height)
• option to enable dragging stuff around
• PNG only

Depends on #7 and #8.

A CloudFormation Stack can contain other stacks. These might be reachable for further exploration.

• How to indicate you can explore a stack? (In the graph or in the editor?)
• When to check if the referenced stack is reachable?
• How to render the stack?
  • Expand existing graph
  • Replace existing graph
  • Pop up

From issue #3 it is clear that some functionality eventually will need some server-side code.

• determine if you want to use JavaScript for this as well
• implement some sort of remote template loading proxy (check https://github.com/afeld/jsonp.git for inspiration)
• switch current front-end to use the new back-end
• (Optional) update de Readme.md to reflect any application changes
• (Optional) remove the GitHub pages or put some redirect in it

• Pick an integration
• Configure it to run tests and check for JS Hint errors

Currently undefined resources are not rendered. Rendering "the web" or external predefined resources might improve insight in how well access to those is defined in the CloudFormation script.

By delaying the rendering of the graph when editing, the application will look less pushy.

It's not immediately clear you can drop templates on the graph area and editor. A small description might help.

This can either be a help button or a hint section.

If a file is dropped on or otherwise loaded from the file system, the field for loading remote templates is filled.

In several presentations security groups are represented as rectangles around resources (mostly EC2 resources).

By rendering them as rectangles and rendering explicit security group rules as special edges graphs will be clearer to read.

It would be nice to have several styles to choose from. The chosen style will affect the cytoscape elements (borders, text, etc.) and might influence the icons used.

• high contrast style (something clearly visible on black
• simple style (using simple images instead of AWS stuff)
• black on white style
• white on black style
• greyscale style (several shades of black to grey)
• full color style

Given an URL the application should load the document and visualize the template if it's a valid CloudFormation template.

• Able to load and render an example template from AWS
• Able to load a faulty template (the editor shows the template with an error, no graph update)
• Shows URL on successful template loading
• Notify when the URL is not a valid template
• Won't bother trying an invalid URL
• A 40x or 50x status code is shown as notification
• Notifies when redirecting

The application will use the query parameter CFTemplateURL to open a remote template.

Depends on #3.

• Determine the best option to implement a debug mode where there is (more) console.log
• Implement debug mode

When the template is unmodified and loaded from a remote location the page should display a link that allows to embed the graph with the current configuration.

The edit.js currently holds the template "class", it should be extracted to it's own file and some tests need to be written.

The current design is very basic and unappealing. Selecting fonts and applying styling will improve the appeal of the interface.

Currently each nodes & edges collecting function defines how it wants to model a new edge. The specs are matched to the collecting function, but should only test the edge finding function.

![Collecting function calls findEdges which calls the addEdge defined in the collecting function](http://g.gravizo.com/g?
digraph G {
collecting_function [label="Collecting function"];
edge_model [label="Edge model",shape="box",style=filled,color="gray"];
collecting_function -> addEdge [label="creates",style="dotted"];
addEdge -> edge_model [label="defines",style=dashed];
collecting_function -> findEdges [label="calls"];
findEdges -> addEdge [label="calls"];
})

To Do:

• Define the structure of an edge in edge finding function
• Return a flattened collection of found edges
• Fix the specs to match
• Fix collection functions to conform

It should be possible to click through from the graph to the relevant section in the editor.