This introduces a addDynamicFilter() method. We need to handle fixed and
dynamic filters separately for proper parentheises. The latter is not
implemented yet and will follow next.
Tests still broken
This test has a very limited scope: only the save method, and it will catch
very few errors in the inline editor. For that,
\action_plugin_struct_inline must be refactored into more manageable
public methods.
To avoid confusion with the Lookup type, the three different ways of
accessing a schema have now the following names:
* page data - for revisioned struct data attached to a page
* serial data - for an unrevisioned list of struct data attached to a
page
* global data - for an unrevisioned list of struct data not attached to
any page (formaly known as lookup schema)
The editor mechanism used for serial and global data is now called
AggregationEditor
Some reference to lookup schemas is still in the bureaucracy support
part.
Schemas per se are type agnostic, isLookup property is removed. Data is stored and accessed differently based on how it is entered and retrieved.
The crucial change is introduction of the composite key of pid and rid. Previous page data utilizes rid = 0 to differentiate itself. Other types, notably lookup, have autoincrementing rid.
Database migration is not implemented yet.
* lookups:
test translation feature
implement rendering via sub type in Dropdown
fix displayValue for looked up type, more tests
fixed constructor signature
first test for new Dropdown features
adjusted tests for renamed aliases
Add Lookup Support to Dropdown
column aliases need to differ from real column names
use display value as default renderer
introduces getDisplayValue
first part of the refactoring for the SchemaData and SchemaLookupData
classes. Both now inherit from AccessTable which provides common methods
and two factory methods to automatically create the correct class
depending on the schema.
Both classes no longer inherit from Schema. Instead they contain a
Schema as a member variable. This makes it possible to initialize them
with an existing schema (which is required for the factory methods).
The flow is now like this:
1: init a schema (read info from the database)
2: look at the schema to figure out if it's a lookup or not
3: initialize the right Data object with the schema
