b6d5cd1c76
SessionCommandService implemented by delegating to the ProcDispatcher
2016-12-23 23:42:27 +01:00
b3f0605b9b
SessionCommand-facade: consider how to expose command invocation
...
after reading some related code, I am leaning towards a design
to mirror the way command messages are sent over the UI-Bus.
Unfortunately this pretty much abandons the possibility to
invoke these operations from a client written in C or any
other hand made language binding. Which pretty much confirms
my initial reservation towards such an excessively open
and generic interface system.
2016-12-23 07:26:00 +01:00
3fef76e1d7
command-binding( #990 ): add new GenNode based argument binding
...
based on the new generic tuple builder, we're now able to
add a new binding function into the command implementation
machinery, alongside the existing one. As it stands, the
latter will be used rather by unit tests, while the new
access path is what will be actually taken within
the application, when receiving argument binding
messages dispatched via the UI-Bus.
2016-01-29 00:59:34 +01:00
16597fcd99
extend command API to also accept a lib::diff::Rec<GenNode> for arguments
...
WIP: have to decide how the arguments can be unpacked
and how to generate proper runtime type mismatch errors.
2016-01-22 20:29:45 +01:00
005e665c13
clean-up design of the command handling patterns ( #210 )
...
this was a classical example of a muddled and messed-up design,
driven just by the fact that I wanted to "spare" some functions,
with the net effect of writing more functions, plus a proxy class
plus create a lot of confusion for the reader.
This was easy to resolve though, once I resorted to the
general adivice to make public interface methods final,
make the extension ponts protected and never
to chain two extension points
2016-01-22 15:25:08 +01:00
0e10ef09ec
refactoring( #988 ): switch command framework to std::tuple
...
this was rather easy, since the stadard tuple is a drop-in replacement,
and we do nothing special here, beyond inheriting from a tuple type
2016-01-19 03:56:54 +01:00
2704ad4512
decide upon the actual mechanics of command binding and invocation
2015-11-28 08:15:32 +01:00
08e7e3df15
prefer more readable bool operator spelling
...
especially the '!' for negation is sometimes too terse
and easily overlooked.
2015-09-25 03:12:04 +02:00
7be1b7d35d
Switch from TR1 preveiw to the new standard headers
...
- functional
- memory
- unordered collections
2014-04-03 22:42:48 +02:00
d9f84a9bfd
clean up lib/meta namespaces
2011-12-03 03:15:59 +01:00
b9d1899486
cleanup: rectify Proc-Layer namespaces (II)
2011-12-02 17:50:44 +01:00
89a9202c6c
cleanup: remove precompiled headers
...
we don't need them and they even tend to
increase build times due to unnecessary
compound-includes at some core headers
2011-12-01 23:32:34 +01:00
3f1b7651e9
GPL header whitespace
2010-12-17 23:28:49 +01:00
c6d5f8a0b4
Proc Command framework: *first integraton round finished*
2009-10-11 05:57:46 +02:00
0bcbf7fee0
fix further problems uncovered by test; allow for anonymous cloning
2009-10-11 05:57:45 +02:00
17c7160f02
refactor CommandDef, get rid of the possibility of re-defining. YAGNI!
2009-10-11 05:57:45 +02:00
37cd451367
fix sloppy definition of less-than comparison, which caused malfunction of registry
2009-10-11 05:57:45 +02:00
d2acf48587
change semantics of state predicates, as it seems less surprising this way
2009-10-11 05:57:44 +02:00
95db5f9840
clarify state predicates in conjunction with command lifecycle
2009-10-11 05:57:44 +02:00
07de2a767b
implement equality comparison on CommandImpl level
2009-10-11 05:57:44 +02:00
4c3fc9e64d
WIP getting CommandRegistry_test to run
...
(equality on CommandImpl is still missing)
2009-10-11 05:57:43 +02:00
39f50b548c
Ticket #266 : simplify and combine the bind(...) mixin templates into a single header
2009-10-11 05:57:43 +02:00
7fccecacce
WIP using the reverse index to find out the Command-ID
...
this includes using a Command* as key within a std::map
2009-10-11 05:57:39 +02:00
4c9af94e1d
improve and clean up the Command interface
2009-10-11 05:57:39 +02:00
8dc434a141
CommandRegistry implementation (...)
2009-10-11 05:57:39 +02:00
18c357eb4a
start using Symbol datatype instead of a disguised char*
2009-10-11 05:57:38 +02:00
f278d4521c
WIP: to make the ID type usable as hashtable key
2009-10-11 05:51:31 +02:00
925fa685b1
WIP change HandlingPattern to work on CommandImpl rather
2009-09-21 03:11:46 +02:00
b9763b6c16
command frontend sort-of written now, pending integration test
2009-08-10 01:32:33 +02:00
5988b1d697
clean up command interface
2009-08-10 01:30:59 +02:00
9f40e4af9c
implemented definition and access of handling patterns
2009-08-09 21:55:47 +02:00
da3cf5a6a6
rework the cmd registry to build on this
2009-08-09 03:48:19 +02:00
09a594d2c5
WIP: considerations for a store-as (clone) operation
2009-08-06 18:00:19 +02:00
a677e2edde
second shot for implementing the binding: better the other way round
2009-08-04 02:25:50 +02:00
155254dd9b
build new cmd impl object within registry
2009-08-03 18:17:41 +02:00
853aff1228
fixed and stubbed until it passes compiler again
2009-08-02 20:57:04 +02:00
327cbc822a
WIP extended binding and invocation to support the convenience shortcuts
2009-08-02 20:55:43 +02:00
4236d0649a
WIP: implement the basic operation of execution pattern
2009-08-02 18:00:03 +02:00
f2126c0764
WIP partially get new proc-layer command impl through the compiler
2009-08-01 23:57:12 +02:00
8971d667cf
WIP more implementation...
2009-08-01 17:14:27 +02:00
c2d9a02303
WIP some more nailing down of implementation details
2009-08-01 02:18:01 +02:00
655177921f
WIP this might solve the race condition
2009-07-30 03:57:19 +02:00
eaa4adddde
WIP more implementation drafting...
2009-07-29 16:55:15 +02:00
19dd606f54
WIP some implementation drafting...
2009-07-27 02:38:53 +02:00
3ebb8d0285
WIP and more stubbing...
2009-07-26 02:00:47 +02:00
1db718c2b3
WIP more stubbing...
2009-07-25 19:21:50 +02:00
211a2dabdd
WIP stubbing undefined operations...
2009-07-24 17:50:14 +02:00
f358f548d1
draft version of CmdClosure and Mutation interface now passing compiler
2009-06-19 19:11:33 +02:00
e951c468a7
WIP: header rename
2009-06-19 14:47:37 +02:00
ba37045b48
WIP: interface/framwork skeleton
2009-06-08 04:50:29 +02:00
