Planning Your Data Model and Taxonomies
Data Model Planning
ActionApps places all the content into a database. That may be the 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 for more info, date when it's published:
The "Need For Field" Guidelines
Note for database savvy: This discussion is equivalent to deciding if you need a new column in your table
So we realize that ActionApps like publishing a structured content, so one of the biggest challenges in your data model planning is suggesting a structure that will not create any barriers for publishing the content you want to publish. In ActionApps you use Fields to define the structure. At most cases, the division of a homogeneous content is straightforward. However, these few guidelines may help.
In deciding whether you need a separate Field for a particular information, consider the following:
- You need a new field if you want to use it for ordering (e.g. order by publish date)
- You need a new field if you want to search by it (e.g. search for a particular name in and only in the "Written by" field)
- You need an new field if you want that particular information to be visually distinct from the rest of the text (e.g. Headline is bold and red colour )
- You may want to create fields to force your editors to not forget about certain things (e.g. always state the original source)
- You should not use fields without a reason - remember that each field will correspond with one User Control in the input form Input Form, and you want to keep the form simple, because simple things work best
.
The "Need For Slice" Guidelines
Note for database savvy: This discussion is equivalent to deciding if you need a new table in your database
Sometimes you simply won't fit all your content into the same structure. You may have News and Events. They share headline and short description. But with events, you need to provide a bit more information, like the location, when does it start, when does it finish, how much is the entry fee. You could of course use the same slice for both, just by not filling this extra info in for news. But it's not practical - the form for news will be more complicated than it has to be, it will be hard to maintain the distinction between news and events. So in this case, you will probably split your content into two groups (News and Events) and deal with those separately.
The guidelines for deciding about the number of slices you need are not as straightforward as the guidelines for fields. The advantages are:
- Assigning permissions (e.g. user A can only edit News not Events)
- Input Forms will be as simple as possible and clearly labeled
- Displaying News and Events separately is straightforward
The disadvantages of splittig are mainly practical
- The Design Templates are kept separate for each slice, with only a limited possibility to share them. That means more work and also changing the design later more complicated (but you do use CSS, dontchya ?)
- Creating a search form which serches through both slices at the same time is quite challenging and needs to be planed in advance
- Some ActionApps ISPs use the number od slices as base for pricing, so things may get a bit more expensive
You need to assess these pros nad cons carefuly, you need a common sense and a bit of experience here to get it right.
Planning your classification system
If the content you are publishing is a bit more than just few items, you probably will want to introduce some system for clasification it, and get your content editor to keep doing using it properly.
Single categories
By clasification we mean a simple thing (at least for start). You have your 1000 news headlines, and you want to put them into few clearly labeled shoe boxes so that you can find them later more easily:
This is a simple taxonomy where each item can belong to exactly one shoebox.
You should foresee how you are going to use this clasification on the web - you create a navigation menu which lists all the categories you have, and by following the link "Health", the visitor will only be presented with the items that relate to Health, not the others.
Multiple categories
In the real life, however, things are not as simple. In certain cases, you realize that you can't decide which shoebox to put the item in, is somehow would fit into two or more, depending on the perspective from which you look at it. So you may want to use a slightly different system of clasification, that is put tags on things rather than put things in shoeboxes:
Each item can have an unspecified (i.e. more than one) category tags on itself. The same item will be listed under Sports and under Health (if you create such sections on your website). That is probabaly a desired behaviour.
Multiple classification
You may want to go futher and use several systems of categories to classify your content and combine them. In the following example we are classifying by topic (i.e. sport, health) which can be a multiple category, and by region - which corner of the world the news came from - which is hopefuly always just one:
Hierarchical constants
All the examples above can be done easily with ActionApps. A little trickier may be the situation when a simple, flat list of categories won't do it for you (or maybe it wil for you but not the peple who use it for clasifying content. What we mean is this very familiar situation:
|- ENTERTAINMENT | \_ Music | \_ Actors | \_ Humor | \_ Dry | \_ British | \_ Not Funny | |- CULTURE | \_ People | \_ Weddings | \_ Magazines
that is when you need your list of categories to further divide into sub categories and so on. This is the list of things that need to be taken care of if you use hierarchical categories
Maintenance of the list:
- Adding and deleting categories
- Moving whole branches, parts of the hierarchy
- Maintaining the hierarchy (mutual relationship between items)
- Maybe creating cross links (links that jump across the tree structure)
Usage:
- On the editors side of things, having means of navigating through the hierarchy quickly to find the word you want to use
- Displaying all items falling under the particular category
- Displaying all items falling under the particular category and all the categories below
- Displaying hierarchical navigation that reflects the structure
- Counting the number of items under each branch
Unlike systems where the tree structure of objects is the base of the navigation (e.g. Drupal, Plone), ActionApps puts records upfront and it's support for hierarchical categories is limited.
Ordinary Categories vs Related Items
ActionApps has a simple system for creating and mainataning lists of categories. There is a place in ActionApps user interface where you can define a named (i.e. My_Categories) list of constants, like this:
| My Categories |
| Category A |
| Category B |
| Category C |
Note: For more or less technical reasons the table above has in fact 2 visible columns, one for the value that will be used in the database, one which will be used for user interaction.
Once you have the list, you can then use it for creating select boxes and other user controls that allow an editor to assign one or more values from the list. Such a list is referred to by it's name and can be shared among several slices.
Now, if you know relational databases, you'd say that you simply use table for the list of categories, as you do for the content itself. In ActionApps, that's equivalent to saying that the categories should also be stored in a designated slice, not some special internal table, and when one wants to assign a category, simply create a relation between two items in two slices. What is content and what is a category sometimes even depends on the interpretation. ActionApps allows you to do that too. The topic is described in detail in the Using_Related_Items chapter.
The example below shows the slight difference between what happens when you use ActionApps Categories and when you use slice to store the list of categories:
Using List of Constants:
|
Content:
|
List of categories (a special table):
|
Using Related Items:
|
Content slice (table):
|
Another slice (table)
|
Note: The number 51265316 is used as an example here, in reality we use long [[Term#Item_ID|Item ID]s.
Conclusion
You have to decide which system you will need in each particular case. Flat systems are simple and you should have no problems with that in ActionApps , even if you use several (multiple) lists of categories. Hierarchical systems are slightly more complicated and can be achieved throught several different ways, which are all discussed in detail elsewhere
ActionApps Categories and Constants
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:
<code> 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) ); </code>
- 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: Private
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, <a href="http://actionapps.org/faq/detail.shtml?x=1707">using them in a search form</a> is described elsewhere.
Hierarchical editor
The new hierarchical editor is accessible from the <a href="http://actionapps.org/faq/detail.shtml?x=1771">standard constant editor</a>
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
see.: Using Related Items
~ToDo: Write Related Items as Categories
