Difference between revisions of "Planning Your Data Model and Taxonomies"

Revision as of 19:02, 12 August 2005 (view source) Marek (talk | contribs) (→‎Data Model Planning) ← Older edit		Revision as of 14:52, 13 August 2005 (view source) Marek (talk | contribs) (→‎Data Model Planning) Newer edit →
Line 2:		Line 2:
	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.		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:	+	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:
	[[Image:news_structure.png]]		[[Image:news_structure.png]]
Line 8:		Line 8:
	<div id="usernotes"><div class="note"><strong>--[[User:Marek|Marek]] 12 August 2005 18:55 (CEST)</strong><div class="text">Warning at an eary stage: If you are planning to create a website which has let's say 1 page for contact info, 1 page for signing a petition, 3 pages T-Shirts ordering and 1 About Us page, ActionApps is probabaly not worth the efforts.		<div id="usernotes"><div class="note"><strong>--[[User:Marek|Marek]] 12 August 2005 18:55 (CEST)</strong><div class="text">Warning at an eary stage: If you are planning to create a website which has let's say 1 page for contact info, 1 page for signing a petition, 3 pages T-Shirts ordering and 1 About Us page, ActionApps is probabaly not worth the efforts.
	</div></div></div>		</div></div></div>
		+
		+	=== The "Need For Field" Guidelines ===
		+
		+	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 bariers for publishing the content you want to publish. In ActionApps you use [[Term#Field|Fields]] to define the structure. At most cases, the division of a homogenous content is staightforward. However, these few guidelines may help.
		+
		+	In deciding whether you need a separate [[Term#Field|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 "Writen by" field)
		+	* You need an new field if you want that particular information to be visually different 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 [[Term:user control#user control]] in the input form [[Term#input form]], and you want to keep the form simple, becuase simple things work best
	== Using Constants and Categories ==		== Using Constants and Categories ==

---

Revision as of 14:52, 13 August 2005

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

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 bariers for publishing the content you want to publish. In ActionApps you use Fields to define the structure. At most cases, the division of a homogenous content is staightforward. 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 "Writen by" field)
• You need an new field if you want that particular information to be visually different 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 Term:user control#user control in the input form Term#input form, and you want to keep the form simple, becuase simple things work best

Using Constants and Categories

ActionApps Categories

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

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