complete wiring of nexus and core services

since, by definition, the Nexus is "the" up-link,
all we need is clever overriding of the relevant
handling functions, so the nexus will care for the routing,
while the CoreService cares for command and presentation
state handling
This commit is contained in:
Fischlurch 2015-12-19 04:05:21 +01:00
parent 449fa16444
commit 37802fd699
4 changed files with 59 additions and 40 deletions

View file

@ -135,7 +135,7 @@ namespace ctrl{
/** record state mark from this subject */
void
inline void
BusTerm::note (GenNode const& mark)
{
theBus_.note (this->endpointID_, mark);

View file

@ -21,15 +21,19 @@
*/
/** @file test/nexus.hpp
** Core hub and routing table of the UI-Bus.
** Any relevant element within the Lumiera GTK UI is connected to the [UI-Bus][ui-bus.hpp]
** through some [bus terminal][bus-term.hpp]. Actually, there is one special BustTerm
** implementation, which acts as router and messaging hub.
/** @file core-service.hpp
** Dedicated service node within the UI-Bus to handle command invocation
** and presentation state. Mostly, the UI-Bus is just a star shaped network
** with one central [routing hub][ctrl::Nexus], and serves to distribute
** generic state and update messages. But there are some special messages
** which need central processing: The command preparation and invocation
** messages and the presentation state tracking messages (state marks).
** The Nexus is configured such as to forward these special messages
** to the [CoreService] terminal, which invokes the dedicated services.
**
** @todo initial draft and WIP-WIP-WIP as of 11/2015
** @todo initial draft and WIP-WIP-WIP as of 12/2015
**
** @see abstract-tangible-test.cpp
** @see TODO_abstract-tangible-test.cpp
**
*/
@ -61,11 +65,11 @@ namespace ctrl{
/**
* Central hub of the UI-Bus.
* This special implementation of the [BusTerm] interface maintains
* a routing table and manages the connections to individual UI-Elements.
* The nexus relies on a dedicated (up)link to the [CoreService] to handle
* command invocation and presentation state.
* Attachment point to "central services" within the UI-Bus.
* This special implementation of the [BusTerm] interface receives and
* handles those messages to be processed by centralised services:
* - commands need to be sent down to Proc-Layer
* - presentation state messages need to be recorded and acted upon.
*
* @todo write type comment
*/
@ -75,37 +79,24 @@ namespace ctrl{
{
virtual void
act (GenNode const& command)
{
UNIMPLEMENTED("receive and handle command invocation");
}
virtual void
note (ID subject, GenNode const& mark) override
{
UNIMPLEMENTED ("forward note messages to the presentation state manager");
UNIMPLEMENTED ("receive and handle presentation state note messages.");
}
virtual void
mark (ID subject, GenNode const& mark) override
{
UNIMPLEMENTED ("route mark messages down to the individual Tangible");
}
virtual BusTerm&
routeAdd(Tangible newNode) override
{
UNIMPLEMENTED ("add a new down-link connection to the routing table");
}
virtual void
routeDetach(ID node) noexcept override
{
UNIMPLEMENTED ("deactivate and remove a down-link route");
}
public:
explicit
CoreService (BusTerm& uplink_to_CoreService, ID identity =lib::idi::EntryID<Nexus>())
: BusTerm(identity, uplink_to_CoreService)
CoreService (BusTerm& backlink_to_Nexus, ID identity =lib::idi::EntryID<CoreService>())
: BusTerm(identity, backlink_to_Nexus)
{ }
};

View file

@ -21,7 +21,7 @@
*/
/** @file test/nexus.hpp
/** @file nexus.hpp
** Core hub and routing table of the UI-Bus.
** Any relevant element within the Lumiera GTK UI is connected to the [UI-Bus][ui-bus.hpp]
** through some [bus terminal][bus-term.hpp]. Actually, there is one special BustTerm
@ -29,7 +29,7 @@
**
** @todo initial draft and WIP-WIP-WIP as of 11/2015
**
** @see abstract-tangible-test.cpp
** @see TODO_abstract-tangible-test.cpp
**
*/
@ -65,7 +65,10 @@ namespace ctrl{
* This special implementation of the [BusTerm] interface maintains
* a routing table and manages the connections to individual UI-Elements.
* The nexus relies on a dedicated (up)link to the [CoreService] to handle
* command invocation and presentation state.
* command invocation and presentation state. This is implemented by wiring
* the aforementioned CoreService terminal as "up-link", while actually
* defining special handling overrides for _all other kinds of messages_.
* The purpose of the Nexus is to route all these _other kinds of messages._
*
* @todo write type comment
*/

View file

@ -38,8 +38,9 @@
//#include "include/logging.h"
#include "test/test-nexus.hpp"
#include "gui/ctrl/nexus.hpp"
#include "lib/depend.hpp"
#include "lib/diff/gen-node.hpp"
#include "lib/idi/entry-id.hpp"
#include "lib/depend.hpp"
//#include <boost/noncopyable.hpp>
//#include <string>
@ -49,6 +50,7 @@
//using std::string;
//using lib::idi::EntryID;
using lib::diff::GenNode;
//using util::contains;
//using util::isnil;
@ -57,10 +59,33 @@ namespace test{
namespace { // internal details
/**
* @internal fake interface backbone and unit test rig
* for simulated command and presentation state handling.
* This implementation embodies the routing functionality
* as found in the [real nexus][gui::ctrl::Nexus], and additionally
* also implements the handler functions of the [gui::ctrl::CoreService].
* The latter allows us to intercept command invocations and presentation
* state messages
*/
class TestNexus
: public gui::ctrl::Nexus
{
virtual void
act (GenNode const& command)
{
UNIMPLEMENTED("receive and handle command invocation");
}
virtual void
note (ID subject, GenNode const& mark) override
{
UNIMPLEMENTED ("receive and handle presentation state note messages.");
}
public:
TestNexus()
: Nexus(*this, lib::idi::EntryID<TestNexus>("mock-UI"))