Planning Your Data Model and Taxonomies

Data Model Planning

ActionApps places all the content into a database. That may be a reason why working with ActionApps resembles working with a database system. With the introduction of "Related Items" at some stage of the development, it had even become a relational database system.

From what we said above comes a (sometimes sad) truth. ActionApps works best when you have a content which leads itself into being stored in a database. That is, in most cases, a significant number of content items, all having the same structure. Imagine news piece, events calendar entry, press release and so on. You have many events but they all can have the same format/structure - headline, short summary, a link fr more info, date when it's published. Warning at the eary stage: If you are planning to create a website which has 2 pages of contact info, one page for signing a petition, 3 pages where you can order T-Shirts and one About Us page, ActionApps is probabaly not worth the efforts.

Constants and Categories

Some fields have a predefined set of possible values --- a constant group. These are usually shown in a select box, multiple check / radio boxes etc. Edit them in Slice Admin -- Fields -- Constants -- Edit / New.

Categories are constants with some special properties. The constant table structure is:

  CREATE TABLE constant ( id char(16) NOT NULL, group_id char(16) NOT NULL, name char(150) NOT NULL, value char(150) NOT NULL, class char(16), pri smallint(5) DEFAULT '100' NOT NULL, PRIMARY KEY (id), KEY group_id (group_id) ); 

• group_id is the constant group name
• name is shown on the Add / Edit item page in the select box or other controls
• value is stored in database (table content) and used by slice.php3, view.php3 etc.
• class_id is used only by categories. It is an identifier of some parent - APC wide - category, usefull when importing items between slices.
• pri is the priority used to sort in the select box etc.

When to use different name and value

How the 'Display' and the 'Store in Database' parts are supposed to be used?

For example the "State" select box (if you want to see it on input form) has the names and values of:

Name	Value
Approved bin	1
Holding bin	2
Trash bin	3

Another example, more real-life - colors select box. There can be names of "Red", "blue", "very bright green", ... and values will be "#FF0000", "#0000FF", "#EEFFEE". In input form you see Red... and on page is then #FF0000

The third example is kind of hint. Suppose you want to have different kinds of item - for example "public", "private", "other" and you want to see this words on compact view. No problem, but you want to see each in different color. So you can define:

name: Private
value: <font color="#FF0000">Private</font>

Order Categories on Input Form as You Wish

You can set the priority order in the constant editing page, and then if you want the output in this order as well, then in the View set the sorting to be "Ascending (or Descending) by Priority"

Propagate changes into current items

Usually if you change a constant value, the current items in the database remain the same. By checking this box you force the changes to be made on the items too. If you change "red" to "cyan", all items with color "red" will be changed to "cyan".

Remember that the constants may be shared by several slices --- if you change a value, the changes may be propagated to some places which you didn't count with. Another danger is that if there were some items with "cyan" before, you can never ever find which item are converted from "red" and which are not.

Changing the constant name doesn't have any effect in the database but changes the look in all Edit / New item pages using the constant group.

Displaying list of constants on a page

For displaying list of constants on the page you can use specila type of view - Constant view Constant view is quite normal view, just like item listing view. You can use aliases, conditions or sorting (conds[], sort[], als[]) (from AA v2.6). Following table shows aliases, which you can use for the design. Many of the aliases have also its own "field_id", which is presented in the second table column. The "field ids" you can use, if provided aliases do not fill your needs or if you want to use conds[] or sort[].

_#NAME###_	const_name	Constant name
_#VALUE##_	const_value	Constant value
_#PRIORITY	const_pri	Constant priority
_#GROUP##_	const_group	Constant group id
_#CLASS##_	const_class	Category class (for categories only)
_#COUNTER_		Constant number
_#CONST_ID	const_id	Constant unique id (32-haxadecimal characters)
_#SHORT_ID	const_short_id	Constant unique short id (autoincremented from '1' for each constant in the system)
_#DESCRIPT	const_description	Constant description
_#LEVEL##_	const_level	Constant level (used for hierachical constants). If you want to display hierarchical constants in its hierarchy (so constant on second level have two spaces before the name), you can use following AA expression: {switch({_#LEVEL##_})1: :2:  :3:   }

Hierarchical constants

What are hierarchical constants? Imagine some keywords allowing to quickly find items of interest --- you have a top-level keyword Country, a first-level keyword United Kingdom and a second-level keyword Leeds. The support has three parts: Editing of the constants and choosing them in the Add / Edit item in AA control panel is described here, using them in a search form is described elsewhere.

Hierarchical editor

The new hierarchical editor is accessible from the standard constant editor by the button "Edit in Hierarchical editor".

The standard and the hierarchical editor are in some sense interchangeable --- you can edit constants in both and it will not damage the structure.

The hierachical editor shows several level boxes. When you choose an item in some level, the next level box will be updated. Because usually the constant Name and Value are the same, there is a check box "Copy value from name" which allows you to only edit the Name box. You can change the editor view by the options at the bottom of the page:

• Hierarchical --- uncheck to get back to the standard constant editor,
• Hide value --- hide the value box, the value will be always copied from the name
• Levels horizontal --- should the level boxes be organized horizontal or vertical?
• Level count --- count of level boxes

Changes to the view setting will take effect only after using "Save all changes to database".

Input type "Hierarchical constants"

To take advantage of the constants ordered into a hierarchy, use the "Hierachical constants" input type for a field containing the constants. This view allows the user to go through the constants by level boxes in the same way as in the hierarchical constant editor. The values chosen are filled into a multiple-select-box field.

Check the "wizard with help" about parameters.

Related Items as Categories

~ToDo: Write Related Items as Categories