|
Together
with database meta information, WAMmodel fuels WAM. The WAMmodel design
pursued minimalism and no redundancy regarding what the database meta
information already provides. We fought very hard to grow the WAMmodel
structure as little as possible to its current state, but real and
reasonable requirements from customer projects determined it:
|
WAMmodel
table
|
Why
we could not avoid it
|
|
WAM_PRESENTATION
|
Database
engines do not provide a place for multi-lingual strings attached to
database objects. Without records here WAM still functions, but with
much less power.
|
|
WAM_ROW_COLUMN
|
|
|
WAM_LOOKUP_COLUMN
|
Although
foreign keys determine the basic mechanics of looking up values in
related tables, it is necessary to specify what columns are relevant
|
|
WAM_LIST
|
Need
a place to store current search criterion/filter, and a couple other
important list attributes
|
|
WAM_LIST_COLUMN
|
Need
to specify the SELECT behind the list, and to persist personalized
list configurations (user maintained)
|
|
WAM_CRITERION
|
Need
to persist personalized list search criteria/filters (user
maintained)
|
|
WAM_PROCEDURE_CALL
|
The
database and the file system already know what are the procedures,
but we need to specify they’re actually callable from somewhere,
whether a confirmation dialog is needed, etc.
|
|
WAM_CONSTRAINT_VIEW_USAGE
|
Foreign
keys and foreign key paths are so useful for interface generation
that we couldn’t live without simulating them among VIEWs too;
every dba loves the flexibility and control of VIEWs
|
|
WAM_TABLE_GROUP
|
Sometimes
users get confused by too many choices, and this provides (optional)
structuring of tables into groups or “application areas”
|
|
WAM_TREE
|
Not
all reflexive relations in tables are to be displayed as trees; a
single record here specifies so.
|
Each
table has only juicy, no redundant information; WAM introspects other
items from the database meta information once, and caches it automatically
for efficiency. For detailed table structure see the WAM
manual.
|