Commit graph

24 commits

Author SHA1 Message Date
1328ef4aa6 solution: how to retrieve syntactic representation
there is now a mechanism to allow sprcialised queries
to generate this syntactic representation only on demand

The actual concrete representation e.g. for scope queries
still remains TODO, but this won't really change
until we target the integration of a real resoloution engine
2013-01-02 04:18:05 +01:00
65feeb83fd supply some documentation about lumiera::Query 2013-01-02 03:32:49 +01:00
e902757a14 (DRAFT) refactor the way how to retrieve the syntactic query representation
there can't be a callback from the base ctor;
instead the subclass must pass a QueryText definition
2012-12-29 00:31:24 +01:00
01792739f3 change Query ordering and hash to include the type information 2012-12-26 01:11:57 +01:00
d73c2fa842 adapt the fake-config-rules to use the new Query::Builder 2012-12-25 01:16:19 +01:00
9369709a46 fix breakage uncovered by unit-test 2012-12-24 03:20:52 +01:00
bccb7a11b5 restore defs-registry Unit test 2012-12-22 22:01:51 +01:00
a9600387ba refactor defaults-manager to use the reworked query interface 2012-12-22 00:39:23 +01:00
5cddc57932 WIP extend query with a warpper for indexing and ordering
...to extract the syntetic ordering from
DefsRegistry and make that a responsibility
of the (internal) syntactic representation
of the query.

doesn't pass the compiler yet
2012-12-17 23:17:32 +01:00
1bde72cccf implement another builder function; adapt OutputDesignation 2012-12-11 04:45:18 +01:00
08ff817afd implement builder/accesor function; adapt StructFactory 2012-12-09 02:42:36 +01:00
8630e888a5 integrate (placeholder) query definition
effectively this joins the two existing lines
of "Query" classes into one systematic representation
Next step would be to move all mutation operations
over to the Query::Builder
2012-12-07 01:49:35 +01:00
d306bb3cdf fix includes 2012-12-03 00:18:18 +01:00
5dfe5e099f refactor namespaces for query and defaults manager 2012-12-01 08:44:07 +01:00
626b1d4356 re-arrange query- rules- and resolver facilities within Core
the rules-based configuration and query system
will be located within the core application,
while the concrete implementation facilities
are expected to reside within the session or
maybe also the GUI.

This is kind of a 'rochade' refactoring to resolve
circular library dependencies and confine the parts
dependant on the session and MObjects to the Proc-Layer

And while we're in the middle of chainsaw surgery,
we'll concentrate further query-based facilities
alongside the config-rules within the App core.
2012-11-27 02:17:21 +01:00
Christian Thaeter
3654473b75 WIP: Merge common into lib
* breaks lumigui linking
 * test non functional yet
 * tools cant not be linked because of cross dependency problems
2008-12-17 17:53:32 +01:00
98005b10ae factor out placeholder for a (planned) Symbol datatype 2008-12-15 13:33:05 +01:00
b86a8605e7 now complete and passing the compiler 2008-04-07 03:19:24 +02:00
b53d8655fd yet another helper function: remove matching term from query string 2008-04-06 08:56:18 +02:00
6596699f6e WIP code for handling registration of defaults objects.
Missing some TODOs and test coverage
2008-03-31 03:21:28 +02:00
c4128c9816 merge Lumiera renaming
WIP doesn't pass the compiler (not due to the merge)
2008-03-10 08:38:59 +01:00
ea0416881e WIP towards a asset::Struct naming scheme 2008-02-18 04:16:53 +01:00
d33242b8cb filled in lots of daunting details regarding structural assets.
StructFactury still very preliminary. Now able to fill the table with mock queries.
TODO: fix assertion failure...
2008-02-10 17:23:16 +01:00
430f38ab2f started a mock implementation for the capability queries.
Later on, I want to embedd Prolog, but for now it is more important to get ahead with the builder...
2008-01-18 16:43:53 +01:00
Renamed from src/proc/asset/query.hpp (Browse further)