Files @ 69ca2b2fc133
Branch filter:

Location: light9/web/live/README.md

drewp@bigasterisk.com
overcomplicated attempt at persisting the pane layout in the rdf graph

this was hard because we have to somehow wait for the graph to load before config'ing the panes
This is an editor of :Effect resources, which have graphs like this:

    <http://light9.bigasterisk.com/effect/effect43> a :Effect;
    rdfs:label "effect43";
    :publishAttr :strength;
    :setting <http://light9.bigasterisk.com/effect/effect43_set0> .

    <http://light9.bigasterisk.com/effect/effect43_set0> :device dev:strip1; :deviceAttr :color; :scaledValue 0.337 .

# Objects

SyncedGraph has the true data.

Effect sends/receives data from one :Effect resource in the graph. Only Effect knows that there are :setting edges in the graph. Everything else on the page
sees the effect as a list of (effect, device, deviceAttr, value) tuples. Those values are non-null. Control elements that aren't contributing the effect
(_probably_ at their zero position, but this is not always true) have a null value.

GraphToControls has a record of all the control widgets on the page, and sends/receives edits with them.

We deal in ControlValue objects, which are the union of a brightness, color, choice, etc. Some layers deal in ControlValue|null. A null value means there is no
:setting for that device+attribute

SyncedGraph and GraphToControls live as long as the web page. Effect can come and go (though there is a plan to make a separate web page url per effect, then
the Effect would live as long as the page too)