Commit graph

22 commits

Author SHA1 Message Date
09359cf92a ElementAccess: initial brainstorming about the interface mechanics 2018-04-07 02:28:29 +02:00
2f899a921c ViewSpec: draft next steps to address
...should implement the generic invocation in ViewLocator,
without actually implementing the backing UI element allocation logic
2018-04-05 19:43:10 +02:00
71bb2b48b6 ViewSpec: pick up with dependency-injection into the DSL tokens (#1126)
Attempt 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


FIRST STEP is to expose the Navigator as generic "LocationQuery" service
through lib::Depend<LocationQuery>
2018-04-04 03:29:26 +02:00
b6360b2e9c LocationSolver: automatically inject persp(UIC_ELIDED) (closes #1128)
decided to add a very specific preprocessing here, to make the DSL notation more natural.
My guess is that most people won't spot the presence of this tiny bit of magic,
and it would be way more surprising to have rules like

UICoord::currentWindow().panel("viewer").create()

fail in most cases, simply because there is a wildcard on the perspective
and the panel viewer does not (yet) exist. In such a case, we now turn the
perspective into a "existential quantified" wildcard, which is treated as if
the actually existing element was written explicitly into the pattern.
2018-02-17 05:11:34 +01:00
0f26f1e0f4 LocationSolver: Documentation and clean-up (#1127) 2018-02-17 03:45:07 +01:00
da8fd6a031 LocationSolver: use the "elided" marker for realistic create rules
...actually just more test coverage,
the feature is already implemented.

What *could* be done though is to inject that UIC_ELIDED marker
on missing perspective specs in create clauses automatically...
2018-02-16 07:34:48 +01:00
6665fb68d6 LocationSolver: decide not to implement match based on context (#1130)
This looks like YAGNI, and it would be non trivial to implement.
But since the feature looks important for slick UI behaviour,
I've made a new ticket and leave it for now
2018-02-16 03:24:37 +01:00
f3791297d6 LocationSolver: cover most standard usage situations
with the exception of some special situations,
which require additional features from the engine,
especially binding-on-context

Not sure though if I'll implement these or say YAGNI
2018-02-16 01:59:51 +01:00
60d40a6a6e LocationSolver: concept for standard usage situation test coverage
...using a fixed set of rules this time,
while injecting a different (simulated) UI tree for each testcase
2018-02-14 04:42:19 +01:00
98cab32a08 LocationSolver: several rule match test cases 2018-02-14 03:02:44 +01:00
9249c513a9 LocationSolver: wildcard match test cases 2018-02-13 03:13:53 +01:00
92bf317d29 LocationSolver: long explicit path test cases
...and here a bug was hiding. gotcha
2018-02-13 02:46:43 +01:00
9fe314ad04 LocationSolver: testcases regarding perspective
TODO support for existentially quantified perspective to match against
"just the" perspectice, disregarding the actual value
2018-02-13 02:26:03 +01:00
c11e557b45 LocationSolver: smallest possible query test cases
querying on window level (=root level)
2018-02-11 04:36:11 +01:00
e04f61fe0d LocationSolver: length discriminating test cases 2018-02-11 04:16:58 +01:00
820abe2bef LocationSolver: provide DSL notation to write "create clauses" 2018-02-11 04:00:59 +01:00
7a167c4c3a LocationSolver: draft pattern for writing those test cases
...which shows: we also need a DSL mechanism for writing "create clauses"
2018-02-11 02:34:56 +01:00
65a86bc426 LocationSolver: define extensive test coverage to be written (#1127) 2018-02-10 02:03:09 +01:00
6d0e8a35a6 LocationSolver: simple unit test PASS 2018-02-10 00:34:24 +01:00
bf314482da LocationSolver: draft the simple usage scenario (unit test) (#1127) 2018-02-08 00:37:02 +01:00
10d2cafba9 LocationSolver: draft entities involved in location solving (#1127)
basically this will be built on top of the path matching / resolving mechanism coded thus far.
but we'll need some additional flags and some DSL magic
2018-02-07 04:03:39 +01:00
136e78d023 DockAccess: decide on next steps towards integration (#1126) 2018-02-01 23:08:43 +01:00