view spec DSL

[Ichthyostega]

Create a DSL-like comprehensive notation to describe where an UI element shall be created or located.
This is an essential constituent of UI behaviour logic and must not be hard wired and mixed up with UI event handling code.

For now we strive at an internal DSL, with a possible future extension to parse a similarily structured configuration notation into those DSL entities.

[Ichthyostega]

all the necessary foundations are in place now

[Ichthyostega]

The problem how to access the LocationSolver service turns more and more into an impediment, which affects the structure of the DSL as a whole. If we want to do it in a clean way, the DSL becomes littered with this cross-cutting concern; if instead we want to keep the DSL simple and focussed, we have to resort to magic: Effectively the GUI, once started, has do drop its actual service implementation into a global variable.

Well, this sounds familiar; it is Dependency Injection.
Now this does not mean we need a DI-Container, but it should be taken as an indication that the previously used provisorium with singletons and ad-hoc installed service instances is no longer adequate. Nothing to be concerned about -- our foundation is solid, an now is the right time to augment it: #1086

[Ichthyostega]

Now I'll need to find my way back to the point where the digression regarding dependency-injection started.

As it turns out, this was a valuable digression, since we can rid ourselves
from lots of ad-hoc functionality, which basically does in a shitty way
what DependencyFactory now provides as standard solution

Especially the tricky points with starting up the global context in the GUI becomes much simpler now

[Ichthyostega]

Issues of integration are basically settled
Funny enough, it was quite easy now, after the rework of lib::Depend

remaining TODO

• finish the ViewSpecDSL_test #1129
• especially cover the alternatives
• add a test case to document the high-level invocation
• which also involves to implement this high-level invocation in ViewLocator

NOT to be solved here right now

• the actual delegation from within the DSL tokens
• the actual navigation mechanism, as abstracted by Navigator (which basically requires all of the UI internals to be set)
• the actual addressing of Panels and widgets
• the actual allocation of concrete new widgets within concrete UI elements

[Ichthyostega]

As of 6/2018, it seems futile to continue design work on those topics,
since far too much of the actual UI internals remains to be settled first.

Thus I'll split off the remaining work into #1143 and close this ticket, since the major design work can be considered as done

[Undercover Agent]

Migration MasterTickets ⟼ Subtickets-plugin