diff --git a/src/lib/diff/diff-message.hpp b/src/lib/diff/diff-message.hpp index 0dd1f869a..abd736d0a 100644 --- a/src/lib/diff/diff-message.hpp +++ b/src/lib/diff/diff-message.hpp @@ -33,8 +33,10 @@ ** be a callback actually to retrieve the diff content. ** ** @todo as of 1/2017 this is placeholder code and we need a concept //////////////////////////////////////////TICKET #1066 : how to pass diff messages + ** @todo as of 8/2017 I am still rather clueless regarding the concrete situation to generate DiffMessage, + ** and as a move into the dark I'll just define it to be based on IterSource... ** - ** @see [AbstractTangible_test] + ** @see AbstractTangible_test ** @see mutation-message.hpp ** */ @@ -45,8 +47,10 @@ #include "lib/error.hpp" +#include "lib/iter-source.hpp" +#include "lib/diff/tree-diff.hpp" +#include "lib/diff/gen-node.hpp" -#include #include @@ -55,23 +59,40 @@ namespace diff{ using std::string; - + using DiffStep = TreeDiffLanguage::DiffStep; + using DiffSource = IterSource; /** - * @todo placeholder + * Opaque message to effect a structural change on a target, which is + * likewise only known in an abstract way, as being specifically structured. + * Sending such messages typically allows some _implemention defined_ part within + * the Session to communicate structure and content to some other _implementation defined_ + * part within the UI-Layer, without the necessity of both partners to be tightly coupled on + * implementation level or even know much about the other's implementation details. As motivation, + * contrast this to a naive UI implementation, which directly accesses some backend data structure; + * any change to the backend implementation typically affects the UI implementation on a detail level. + * + * @todo WIP 8/2017 -- as a bold step towards the solution yet to be discovered, + * I now define DiffMessage to be based on IterSource, which means + * to add yet another abstraction barrier, so the implementation of diff generation + * remains confined within the producer of DiffMessages. + * @warning yet still the fundamental problem remains: the production context of such + * diff messages need to be conserved beyond the producer's thread context, because + * it will be pulled asynchronous from within the UI event thread! */ class DiffMessage - : boost::noncopyable + : public DiffSource::iterator { - public: - - void - magically_extract_MutationMessage() - { - UNIMPLEMENTED ("miracle No #1066"); //////////////////////////////////////////TICKET #1066 : how to pass diff messages - } + /** + * DiffMessage builder: + * take ownership of an opaque heap allocated context + * from which the concrete diff can be pulled on demand + */ + DiffMessage(DiffSource* diffGenerationContext) + : DiffSource::iterator{DiffSource::build (diffGenerationContext)} + { } }; diff --git a/tests/gui/abstract-tangible-test.cpp b/tests/gui/abstract-tangible-test.cpp index 871e26f80..674a93fa6 100644 --- a/tests/gui/abstract-tangible-test.cpp +++ b/tests/gui/abstract-tangible-test.cpp @@ -554,17 +554,15 @@ namespace test { * handled and applied to the receiver by Lumiera's diff framework. * * This test uses the MockElem to simulate real UI elements; - * to be able to verify the diff application, MockElm is already - * preconfigured with a _diff binding_, and it exposes a set of - * attributes and a collection of child mock elements. Basically, - * the diff mechanism allows to effect structural changes within - * an otherwise opaque implementation data structure. For this - * to work, the receiver needs to create a custom _diff binding_. - * Thus, each subclass of Tangible has to implement the virtual - * function Tangible::buildMutator() and hook up those internal - * structures, which are exposed to changes via diff message. - * Note especially how child UI elements are added this way, - * to populate the contents of the UI. + * to be able to verify the diff application, MockElm is already preconfigured + * with a _diff binding_, and it exposes a set of attributes and a collection + * of child mock elements. Basically, the diff mechanism allows to effect + * structural changes within an otherwise opaque implementation data structure. + * For this to work, the receiver needs to create a custom _diff binding_. + * Thus, each subclass of Tangible has to implement the virtual function + * Tangible::buildMutator() and hook up those internal structures, which + * are exposed to changes via diff message. Note especially how child + * UI elements are added this way, to populate the contents of the UI. * * The diff itself is an iterable sequence of _diff verbs_. * Typically, such a diff is generated as the result of some operation diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index a2a5fe6f5..be6e3b6a4 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -1045,6 +1045,9 @@ + + + @@ -1408,26 +1411,155 @@ - + - + - + - + - - - - + + + + + - - - + + + + + + + + + + + + + + + - + + + + + + + + + + + + + + + + + + + + + + +

+ ist schon schlimm genug.... +

+ + + + + + + + + + + + + + +

+ ...denn eigentlich geht es nur um ein einfaches Producer-Interface, +

+

+ das einen Element-Pointer durchreicht. Das einzige Problem, das ich sehe, +

+

+ ist, daß hier ownership übertragen wird. +

+ + + + + + + + + + + + + + + + + + + + +

+ nämlich +

+
    +
  • + ein sehr theoretisches und anspruchsvolles Konzept +
    • +
  • + der Zwang, das auf jedem Empfänger umzusetzen +
    • +
  • + die hablseidene Trickserei mit der konkreten Puffergröße +
    • +
  • + den double-dispatch im Diff-Framework selber +
    • +
  • + das Variant-basierte GenNode-Framework +
    • +
+ + + + + + + + + + +

+ das wird sowiso ein Desaster +

+ + + + + + + + + + + + + + + + @@ -1443,9 +1575,10 @@ und man damit jedes diff-iterable einbetten kann.

- + + - +