yellow team mailing list archive

[Benjamin Saller <benjamin.saller@xxxxxxxxxxxxx>]

Example module for env view refactor

Looking to get more eyes on the way the module code is playing out. In
particular I'm much more interested in if the various parts fit together in
a way that makes sense to people than an details of the impl.

The basic pattern is this

EnvironmentView has a Topology object which is a subclass of the d3-component 
stuff. The Env view binds modules to the topology (from app/views/topology/).

The framework will look at each modules declarative structures for events and
bind behavior. The basic cycle the view moves through then is 

update() <- called on data change to recompute view models, things like
            position information.
			
render() <- draw the current scene. Render itself support the notion of one
            time setup code and incremental rendering. For the most part 
			scene mutation will happen in the event handlers though, those
			behaviors are facilitated by the framework but not controlled by
			it.
			
Modules attempt to aid in keeping inter-module code loosely coupled. This is
done by encouraging use of custom YUI events. Module.events.yui is one of the
event binding structures available from the framework, modules can listen for
changes that may be of interest to other modules and fire events which can
trigger handlers. 

There isn't always a clean line between what should live in a module and the
topology object itself but the rule of thumb is that if it can reasonably go
in a module it should, the topology layer is mainly configuration and
coordination.

Looking forward to comments. Thanks.
-- 
https://code.launchpad.net/~hazmat/juju-gui/component-modules/+merge/135501
Your team Juju GUI Hackers is requested to review the proposed merge of lp:~hazmat/juju-gui/component-modules into lp:juju-gui.