|
|
| Line 1: |
Line 1: |
| − | == 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:
| |
| − |
| |
| − | [[Image:news_structure.png]]
| |
| − |
| |
| − | <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>
| |
| − |
| |
| − | === 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 [[Term#Field|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 [[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 "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 [[Term#User Control|User Control]] in the input form [[Term#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 [[Term#Slice|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)
| |
| − | * [[Term#Input Form|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 [[Term#Design Template]]s 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 [[Searching With ActionApps|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 clasification 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:
| |
| − |
| |
| − | [[Image:Clasification1.png]]
| |
| − |
| |
| − | 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:
| |
| − |
| |
| − | [[Image:Clasification2.png]]
| |
| − |
| |
| − | 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.
| |
| − |
| |
| − | <div id="usernotes"><div class="note"><strong>--[[User:Marek|Marek]] 13 August 2005 17:44 (CEST)</strong><div class="text">'''Warning:''' If you implement your categories using ActionApps constants (i.e. not Related Items) , and an item can have multiple categories '''and you use group by categories''', you may get surprising results. Avoid this by either not using group by or use Related Items.</div></div></div>
| |
| − |
| |
| − | === Multiple clasification ===
| |
| − | You may want to go futher and use several systems of categories to clasify your content and combine them. In the following example we are clasifying 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:
| |
| − |
| |
| − | [[Image:Clasification3.png]]
| |
| − |
| |
| − | === 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:
| |
| − |
| |
| − | <table border=1>
| |
| − | <tr><td>'''My Categories'''</td></tr>
| |
| − | <tr><td>Category A</td></tr>
| |
| − | <tr><td>Category B</td></tr>
| |
| − | <tr><td>Category C</td></tr>
| |
| − | </table>
| |
| − |
| |
| − | ''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: ====
| |
| − | <table width=75%>
| |
| − | <tr>
| |
| − | <td>
| |
| − | Content:
| |
| − | <table border=1>
| |
| − | <tr>
| |
| − | <td>
| |
| − | '''''Headline'''''
| |
| − | </td>
| |
| − | <td>
| |
| − | '''''Category'''''
| |
| − | </td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td>
| |
| − | EC approves Monsanto GM maize
| |
| − | </td>
| |
| − | <td>
| |
| − | <font color=red><strong>GMO</strong></font>
| |
| − | </td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td>
| |
| − | ...
| |
| − | </td>
| |
| − | <td>
| |
| − | ...
| |
| − | </td>
| |
| − | </tr>
| |
| − | </table>
| |
| − | </td>
| |
| − | <td>
| |
| − | List of categories (a special table):
| |
| − | <table border=1>
| |
| − | <tr>
| |
| − | <td>
| |
| − | '''''Value'''''
| |
| − | </td>
| |
| − | <td>
| |
| − | '''''Name'''''
| |
| − | </td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td>
| |
| − | <font color=red><strong>GMO</strong></font>
| |
| − | </td>
| |
| − | <td>
| |
| − | Genetic manipulations
| |
| − | </td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td>
| |
| − | ...
| |
| − | </td>
| |
| − | <td>
| |
| − | ...
| |
| − | </td>
| |
| − | </tr>
| |
| − | </table>
| |
| − | </td>
| |
| − | </tr>
| |
| − | </table>
| |
| − | ==== Using Related Items: ====
| |
| − | <table width=75%>
| |
| − | <tr>
| |
| − | <td>
| |
| − | Content slice (table):
| |
| − | <table border=1>
| |
| − | <tr>
| |
| − | <td>
| |
| − | '''''Unique ID'''''
| |
| − | </td>
| |
| − | <td>
| |
| − | '''''Headline'''''
| |
| − | </td>
| |
| − | <td>
| |
| − | '''''ID of a Category'''''
| |
| − | </td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td>
| |
| − | 2381725
| |
| − | </td>
| |
| − | <td>
| |
| − | EC approves Monsanto GM maize
| |
| − | </td>
| |
| − | <td>
| |
| − | <font color=red><strong>51265316</strong></font>
| |
| − | </td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td>
| |
| − | ...
| |
| − | </td>
| |
| − | <td>
| |
| − | ...
| |
| − | </td>
| |
| − | <td>
| |
| − | ...
| |
| − | </td>
| |
| − | </tr>
| |
| − | </table>
| |
| − | </td>
| |
| − | <td>
| |
| − | Another slice (table)
| |
| − | <table border=1>
| |
| − | <tr>
| |
| − | <td>
| |
| − | '''''Unique ID'''''
| |
| − | </td>
| |
| − | <td>
| |
| − | '''''Abbreviation'''''
| |
| − | </td>
| |
| − | <td>
| |
| − | '''''Long Name'''''
| |
| − | </td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td>
| |
| − | <font color=red><strong>51265316</strong></font>
| |
| − | </td>
| |
| − | <td>
| |
| − | GMO
| |
| − | </td>
| |
| − | <td>
| |
| − | Genetic manipulations
| |
| − | </td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td>
| |
| − | ...
| |
| − | </td>
| |
| − | <td>
| |
| − | ...
| |
| − | </td>
| |
| − | <td>
| |
| − | ...
| |
| − | </td>
| |
| − | </tr>
| |
| − | </table>
| |
| − | </td>
| |
| − | </tr>
| |
| − | </table>
| |
| − |
| |
| − |
| |
| − | Note: The number <font color=red><strong>51265316</strong></font> 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 ===
| |
| − | <aafaq id=1771> ~ToDo:1771 Constants and Categories </aafaq>
| |
| | === Hierarchical Constants === | | === Hierarchical Constants === |
| | <aafaq id=1711> ~ToDo:1711 Using hierarchical constants</aafaq> | | <aafaq id=1711> ~ToDo:1711 Using hierarchical constants</aafaq> |
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.
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:
Changes to the view setting will take effect only after using "Save all changes to database".
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.
