//how to access proc layer commands from the UI and to talk to the command framework//
+
+!Command access DSL
+{{red{WIP 4/2017}}} first rough draft of a framework for dealing with proc layer commands from within UI code
+{{{
+Symbol ADD_CLIP = CmdAccess::for (cmd::scope_addClip, INTO_FORK);
+cmdAccess(ADD_CLIP).bind (scope(HERE), element(RECENT))
+issueCommand (cmdAccess(ADD_CLIP).execute());
+}}}
+Notable details
+* we use some standardised context designators
+*;~INTO_PROJECT
+*;~INTO_FORK
+*;~INTO_BIN
+* we rely on a naming scheme for the command definitions
+* access to commands is prepared by defining an instanceID as a local Symbol
+* we use some standardised ''roles'' for the command arguments
+* the binding involves //argument resolver expressions//
+*;scope(HERE)
+*;element(RECENT)
+* moreover, we rely on generation of messages for use on the UI-Bus. Somethimes, these are even issued implicitly
+
+The question //how to connect the notion of an ''interface action'' to the notion of a ''command'' issued towards the [[session model|HighLevelModel]].// * actual design of command invocation in the UI → GuiCommandCycle @@ -2604,7 +2628,7 @@ This contrastive approach attempts to keep knowledge and definition clustered in → CommandSetup
//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.
@@ -2639,7 +2663,7 @@ from these use cases, we can derive the //crucial activities for command handlin
* the latter in turn retrieves a new command instance ID from the {{{CmdInstanceManager}}} in Proc
* and the latter keeps a smart-ptr corresponding to this instance in its internal registration table
* within the UI, a command instance corresponds to a specific invocation trail, and is thus stored within the managing {{{InteractionState}}}
-* ~UI-Elements use the services of {{{CmdAccess}}}, either to get arguments directly, or to act as observer of state changes
+* ~UI-Elements use the services of {{{CmdAccess}}}, either to get arguments directly, or to act as observer of state changes → GuiCommandAccess
* when a command is completely parametrised, it can be invoked. The managing {{{InteractionState}}} knows about this
* 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
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index c2fb61594..5a622ebbd 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -11685,8 +11685,8 @@
-
-
+
@@ -12032,10 +12032,158 @@
-
+
+
+
+
+
+
+
+
+
+ managed diese Komponente nicht
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ aufwendiges Nebenthema
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Symbol ADD_CLIP = CmdAccess::for (cmd::scope_addClip, INTO_FORK);
+
+
+ cmdAccess(ADD_CLIP).bind (scope(HERE), element(RECENT))
+
+
+ issueCommand (cmdAccess(ADD_CLIP).execute());
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ die DSL muß so konstruiert werden,
+
+
+ daß die Syntax-Elemente nahtlos simplifiziert werden können,
+
+
+ in eine Form, die sich unmittelbar jetzt implementieren läßt
+
+
+ und mit einfachen, direkt gegebenen Objekten
+
+
+
+
+
+
+
+
@@ -12234,8 +12382,8 @@
-
+