more planning of command invocation structure
This commit is contained in:
parent
cfe9cc96f6
commit
ada40609f5
3 changed files with 64 additions and 10 deletions
Binary file not shown.
|
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 23 KiB |
|
|
@ -2582,7 +2582,7 @@ This contrastive approach attempts to keep knowledge and definition clustered in
|
|||
→ GuiCommandCycle
|
||||
</pre>
|
||||
</div>
|
||||
<div title="GuiCommandCycle" creator="Ichthyostega" modifier="Ichthyostega" created="201703031817" modified="201703150206" tags="design operational GuiPattern GuiIntegration draft discuss img" changecount="33">
|
||||
<div title="GuiCommandCycle" creator="Ichthyostega" modifier="Ichthyostega" created="201703031817" modified="201703170308" tags="design operational GuiPattern GuiIntegration draft discuss img" changecount="41">
|
||||
<pre>//the process of issuing a session command from the UI//
|
||||
Within the Lumiera UI, we distinguish between core concerns and the //local mechanics of the UI.// The latter is addressed in the usual way, based on a variation of the [[MVC-Pattern|http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller]]. The UI toolkit set, here the GTK, affords ample ways to express actions and reactions within this framework, where widgets in the presentation view are wired with the corresponding controllers vice versa (GTK terms these connections as //"signals"//, we rely on {{{libSigC++}}} for implementation).
|
||||
A naive approach would extend these mature mechanisms to also cover the actual functionality of the application. This compelling solution allows quickly to get "something tangible" up and running, yet -- on the long run -- inevitably leads to core concerns being tangled into the presentation layer, which in turn becomes hard to maintain and loaded with "code behind". Since we are here "for the long run", we immediately draw the distinction between UI mechanics and core concerns. The latter are, by decree and axiom, required to perform without even an UI layer running. This decision gives rise to the challenge how to form and integrate the invocation of ''core commands'' into the presentation layer.
|
||||
|
|
@ -2622,8 +2622,9 @@ from these use cases, we can derive the //crucial activities for command handlin
|
|||
* on invocation, the ID of the instance is sent via UI-Bus to the {{{CmdInstanceManager}}}
|
||||
* which in turn removes the instance handle from its registration table and hands it over into the ProcDispatcher
|
||||
[<img[Access to Session Commands from UI|uml/Command-ui-access.png]]
|
||||
Consequently this means that command instances will be formed //per instance// of InteractionStateManager. Thus, each distinct kind of control system has its own instances, which are kept around, until they are ready for invocation. Each invocation "burns" an instance -- on next access, a new instance ID will be allocated, and the next command invocation cycle starts...
|
||||
</pre>
|
||||
An immediate consequence is that command instances will be formed //per instance// of InteractionStateManager. Each distinct kind of control system has its own instances, which are kept around, until they are ready for invocation. Each invocation "burns" an instance -- on next access, a new instance ID will be allocated, and the next command invocation cycle starts...
|
||||
|
||||
Command instances are like prototypes -- thus each additional level of differentiation will create a clone copy and decorate the basic command ID. Yet this extension process is delegated into multiple stages. Already when a specific InvocationTrail is established, the bare command prototype is specialised, and additionally combined with specific context access rules and maybe even a accessor to retrieve some argument value. The {{{CmdInstanceManager}}} internally maintains and tracks a prepared command instance, supplying a distinct instance number to keep concurrently existing instances apart; instances might be around for an extended period, because commands are enqueued with the ProcDispatcher.</pre>
|
||||
</div>
|
||||
<div title="GuiConnection" modifier="Ichthyostega" created="200812050543" modified="201703031816" tags="GuiIntegration overview" changecount="9">
|
||||
<pre>All communication between Proc-Layer and GUI has to be routed through the respective LayerSeparationInterfaces. Following a fundamental design decision within Lumiera, these interface are //intended to be language agnostic// &mdash; forcing them to stick to the least common denominator. Which creates the additional problem of how to create a smooth integration without forcing the architecture into functional decomposition style. To solve this problem, we rely on ''messaging'' rather than on a //business facade// -- our facade interfaces are rather narrow and limited to lifecycle management. In addition, the UI exposes a [[notification facade|GuiNotificationFacade]] for pushing back status information created as result of the edit operations, the build process and the render tasks.
|
||||
|
|
@ -2782,7 +2783,7 @@ We acknowledge that the gui model is typically used from within the GUI event di
|
|||
The forwarding of model changes to the GUI widgets is another concern, since notifications from session mutations arrive asynchronous after each [[Builder]] run. In this case, we send a notification to the widgets registered as listeners, but wait for //them// to call back and fetch the [[diffed state|TreeDiffModel]]. This callback will be scheduled by the widgets to perform in the GUI event thread.
|
||||
</pre>
|
||||
</div>
|
||||
<div title="GuiModelElements" creator="Ichthyostega" modifier="Ichthyostega" created="201501061138" modified="201511210301" tags="GuiIntegration design draft img" changecount="46">
|
||||
<div title="GuiModelElements" creator="Ichthyostega" modifier="Ichthyostega" created="201501061138" modified="201703170201" tags="GuiIntegration design draft img" changecount="47">
|
||||
<pre>''Building Blocks for the User Interface Model and Control structure''
|
||||
The fundamental pattern for building graphical user interfaces is to segregate into the roles of __M__odel, __V__iew and __C__controler ([[MVC|http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller]]). This approach is so succesful, that it turned into a de-facto standard in commen UI toolkit sets. But larger, more elaborate and specialised applications introduce several cross cutting concerns, which create a tension within this MVC solution pattern.
|
||||
[<img[UI-Bus and GUI model elements|uml/fig158213.png]]
|
||||
|
|
@ -3414,13 +3415,13 @@ From experiences with other middle scale projects, I prefer having the test code
|
|||
[img[Example: Interfaces/Namespaces of the ~Session-Subsystems|uml/fig130053.png]]
|
||||
</pre>
|
||||
</div>
|
||||
<div title="InvocationTrail" creator="Ichthyostega" modifier="Ichthyostega" created="201512190210" modified="201703150336" tags="def GuiIntegration draft" changecount="5">
|
||||
<div title="InvocationTrail" creator="Ichthyostega" modifier="Ichthyostega" created="201512190210" modified="201703161928" tags="def GuiIntegration draft" changecount="7">
|
||||
<pre>//A command in preparation of being issued from the UI.//
|
||||
The actual persistent operations on the session model are defined through DSL scripts acting on the session interface, and configured as a //command prototype.// Typically these need to be enriched with at least the actual subject to invoke this command on; many commands require additional parameters, e.g. some time or colour value. These actual invocation parameters need to be picked up from UI elements, and the process of preparing and outfitting a generic command with these actual values is tracked by an ''InvocationTrail handle''. When ready, finally this handle can be issued on any bus terminal, i.e. on any [[tangible interface element|UI-Element]].
|
||||
|
||||
&rarr; CommandInvocationAnalysis
|
||||
|
||||
An invocation trail represents one specific path leading to the invocation of a command. It is a value object (handle), and it serves as the interface used by the UI-Element to retrieve or supply the arguments and finally to prepare the invocation message(s). But while the invocation trail is generic to some degree, the entity to trigger the command invocation needs explicit and concrete knowledge about the circumstances involved into this invocation. Simply, because in some cases, very specific information need to be provided as argument. For example, a widget just needs to know that the setting of a specific slider will be what becomes a likewise specific argument.
|
||||
An invocation trail represents one specific path leading to the invocation of a command. It is a value object (handle), and it serves as the interface used by the UI-Element to retrieve or supply the arguments and finally to prepare the invocation message(s). But while the invocation trail is generic to some degree, the entity to trigger the command invocation needs explicit and concrete knowledge about the circumstances involved into this invocation. Simply, because in some cases, very specific information needs to be provided as argument. For example, a widget just happens to know that the setting of a specific slider will be what becomes a likewise specific argument.
|
||||
</pre>
|
||||
</div>
|
||||
<div title="JobTicket" modifier="Ichthyostega" created="201202120018" modified="201208311625" tags="spec Rendering draft">
|
||||
|
|
|
|||
|
|
@ -2085,7 +2085,47 @@
|
|||
<node CREATED="1489461838228" ID="ID_283502486" MODIFIED="1489461843087" TEXT="im InteractionDirector"/>
|
||||
<node CREATED="1489461843747" ID="ID_1499714490" MODIFIED="1489461922546" TEXT="die Command-ID beziehen">
|
||||
<icon BUILTIN="forward"/>
|
||||
<node CREATED="1489461856042" ID="ID_1097689316" MODIFIED="1489461862061" TEXT="bedingt Command-ID"/>
|
||||
<node CREATED="1489461856042" ID="ID_1097689316" MODIFIED="1489461862061" TEXT="bedingt Command-ID">
|
||||
<node CREATED="1489715248861" ID="ID_999876408" MODIFIED="1489715252392" TEXT="brauche">
|
||||
<node CREATED="1489715276057" ID="ID_878658276" MODIFIED="1489715279093" TEXT="Basis-ID"/>
|
||||
<node CREATED="1489715297406" ID="ID_601143379" MODIFIED="1489715305201" TEXT="dekoriert durch Invocation-Trail"/>
|
||||
<node CREATED="1489715320435" ID="ID_1521007439" MODIFIED="1489715325174" TEXT="dekoriert durch laufende Nr"/>
|
||||
<node CREATED="1489715326210" ID="ID_1820734132" MODIFIED="1489715331310" TEXT="guten Hash von diesen"/>
|
||||
<node CREATED="1489715461992" ID="ID_115322523" MODIFIED="1489715479858" TEXT=""leere" Basis-ID ohne lfdNr"/>
|
||||
<node CREATED="1489715591582" ID="ID_256884690" MODIFIED="1489715597393" TEXT="inkrement der lfdNr"/>
|
||||
</node>
|
||||
<node CREATED="1489716825126" HGAP="38" ID="ID_969368347" MODIFIED="1489717783561" TEXT="Ansätze" VSHIFT="-1">
|
||||
<node CREATED="1489716845980" ID="ID_816994670" MODIFIED="1489718875217" TEXT="Command-ID-Token">
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
<node CREATED="1489716859034" ID="ID_1342799459" MODIFIED="1489716867940" TEXT="SubID o.ä."/>
|
||||
<node CREATED="1489716870000" ID="ID_907818022" MODIFIED="1489716875547" TEXT="Wert-Semantik"/>
|
||||
<node CREATED="1489716876183" ID="ID_880911498" MODIFIED="1489716883650" TEXT="enthält die lfdNr"/>
|
||||
</node>
|
||||
<node CREATED="1489717087626" ID="ID_1304379039" MODIFIED="1489718872841" TEXT="Registrierungs-Instanz">
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
<node CREATED="1489717094881" ID="ID_890501908" MODIFIED="1489717104332" TEXT="Referenz-Semantik"/>
|
||||
<node CREATED="1489717108735" ID="ID_142693821" MODIFIED="1489717115730" TEXT="enthält direkt den Zähler"/>
|
||||
<node CREATED="1489717116246" ID="ID_1967376157" MODIFIED="1489717129232" TEXT="brauche front-End-Token"/>
|
||||
</node>
|
||||
<node CREATED="1489717203882" ID="ID_199366549" MODIFIED="1489718870140" TEXT="eingebettete Information">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1489717237622" ID="ID_1384169115" MODIFIED="1489717301257" TEXT="Command + Zähler in Hashtable"/>
|
||||
<node CREATED="1489717304621" ID="ID_1984888825" MODIFIED="1489717311967" TEXT="CmdInstanceManager hat Hashtable"/>
|
||||
<node CREATED="1489717425684" ID="ID_205251145" MODIFIED="1489717436846" TEXT="Instance-Management komplett eingekapselt"/>
|
||||
<node CREATED="1489717312532" ID="ID_1911293548" MODIFIED="1489717329029" TEXT="key ist Basis-Cmd-ID + InvocationTrail-ID"/>
|
||||
<node CREATED="1489717395312" ID="ID_1098297494" MODIFIED="1489717405571" TEXT="InvocationTrail speichert nur diese ID"/>
|
||||
<node CREATED="1489717406447" ID="ID_1938762085" MODIFIED="1489717411690" TEXT="Bang sendet nur diese ID"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1489717768805" HGAP="79" ID="ID_119293304" MODIFIED="1489718863072" TEXT="Entscheidung" VSHIFT="4">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1489717797353" ID="ID_899130819" MODIFIED="1489717807068" TEXT="die ersten beiden sind unötig generisch"/>
|
||||
<node CREATED="1489717807872" ID="ID_1209104496" MODIFIED="1489717818826" TEXT="wir bauen ohnehin den Command-Cycle fest ein"/>
|
||||
<node CREATED="1489717844003" ID="ID_97055123" MODIFIED="1489717853605" TEXT="letztgenannte Lösung ist auf den Punkt"/>
|
||||
<node CREATED="1489717927279" ID="ID_845301501" MODIFIED="1489717959263" TEXT="Command-ID erfüllt keine regulierende Funktion"/>
|
||||
<node CREATED="1489717960331" ID="ID_1849715968" MODIFIED="1489717991603" TEXT="viel wichtiger sind die Aktivierungs-Regeln"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1489461862937" ID="ID_1649764088" MODIFIED="1489461871843" TEXT="bedingt Command-Definition"/>
|
||||
<node CREATED="1489461872367" ID="ID_1191906862" MODIFIED="1489461882010" TEXT="bedingt CmdAccessor"/>
|
||||
<node CREATED="1489461905083" ID="ID_1232900605" MODIFIED="1489461911390" TEXT="bedingt Service-Zugang"/>
|
||||
|
|
@ -2182,7 +2222,7 @@
|
|||
<node CREATED="1489547179254" ID="ID_192306839" MODIFIED="1489547197378" TEXT="ist das der richtige Ansatz?">
|
||||
<icon BUILTIN="help"/>
|
||||
</node>
|
||||
<node CREATED="1489547208282" ID="ID_99440101" MODIFIED="1489547228707" TEXT="läßt sich das überhaupt jeh realisieren?">
|
||||
<node CREATED="1489547208282" ID="ID_99440101" MODIFIED="1489690731089" TEXT="läßt sich das überhaupt je realisieren?">
|
||||
<icon BUILTIN="help"/>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -2216,15 +2256,28 @@
|
|||
<node CREATED="1489547498122" ID="ID_1669169317" MODIFIED="1489547504003" TEXT="die Dauer"/>
|
||||
<node CREATED="1489547283807" ID="ID_559442696" MODIFIED="1489547286467" TEXT="der Wert"/>
|
||||
</node>
|
||||
<node CREATED="1489547506625" ID="ID_1063184971" MODIFIED="1489547632364" TEXT="konkret....">
|
||||
<node CREATED="1489547506625" ID="ID_1063184971" MODIFIED="1489719071018" TEXT="konkret....">
|
||||
<arrowlink COLOR="#4d2a67" DESTINATION="ID_1622068086" ENDARROW="Default" ENDINCLINATION="-9;-36;" ID="Arrow_ID_717312728" STARTARROW="None" STARTINCLINATION="15;49;"/>
|
||||
<node CREATED="1489547511224" ID="ID_954080965" MODIFIED="1489547530586" TEXT="das UI-Element weiß explizit was gebraucht wird"/>
|
||||
<node CREATED="1489547542852" ID="ID_271774122" MODIFIED="1489547548943" TEXT="und stellt selber das Tupel zusammen"/>
|
||||
<node CREATED="1489547574504" ID="ID_49978062" MODIFIED="1489547582019" TEXT="oder ruft einen Funktor auf"/>
|
||||
<node CREATED="1489547588102" ID="ID_985840704" MODIFIED="1489547597465" TEXT="wodurch die Argument-Typen dokumentiert sind"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1489548252324" HGAP="78" ID="ID_1622068086" MODIFIED="1489548276247" TEXT="das könnte der InvocationTrail sein" VSHIFT="20">
|
||||
<node CREATED="1489548252324" HGAP="78" ID="ID_1622068086" MODIFIED="1489719025991" TEXT="das könnte der InvocationTrail sein" VSHIFT="20">
|
||||
<linktarget COLOR="#4d2a67" DESTINATION="ID_1622068086" ENDARROW="Default" ENDINCLINATION="-9;-36;" ID="Arrow_ID_717312728" SOURCE="ID_1063184971" STARTARROW="None" STARTINCLINATION="15;49;"/>
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1489719178053" ID="ID_1509284806" MODIFIED="1489719184696" TEXT="hat Cmd-ID + eigene ID"/>
|
||||
<node CREATED="1489719186276" ID="ID_929080602" MODIFIED="1489719196230" TEXT="kann entscheiden ob ausführbar"/>
|
||||
<node CREATED="1489719200330" ID="ID_840062807" MODIFIED="1489719208197" TEXT="hat Argument-Accessor"/>
|
||||
<node COLOR="#5e427f" CREATED="1489719212976" HGAP="-52" ID="ID_949699860" MODIFIED="1489719253576" TEXT="noch offen" VSHIFT="45">
|
||||
<font ITALIC="true" NAME="SansSerif" SIZE="12"/>
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node CREATED="1489719257426" ID="ID_1618753270" MODIFIED="1489719266032" TEXT="wer erzeugt den InvocationTrail"/>
|
||||
<node CREATED="1489719267537" ID="ID_963145148" MODIFIED="1489719291065" TEXT="was ist bereits vom Command her definiert"/>
|
||||
<node CREATED="1489719292181" ID="ID_804928267" MODIFIED="1489719304359" TEXT="kann es mehrere konkurrierende Auslegungen geben?"/>
|
||||
<node CREATED="1489719311347" ID="ID_1220954776" MODIFIED="1489719322437" TEXT="oder ist eine Zugriffsstrategie = ein InvocationTrail"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
|
|||
Loading…
Reference in a new issue