This is undoubtedly the most special table in zoglair, having some unique characteristics that make it as important as the registry in Windows OS or the spine in our body!

  • It is the default and primary content provider for both static and dynamic web pages.
  • It is the only table structured as a tree hierarchy, using an advanced data model known as nested set. For this reason, its entries (~rows) are called nodes.
  • As a tree, it offers the flexible and highly useful feature of inheritance. All fields in a parent node are implicitly inherited by the descendants, unless you explicitly change them.
  • It is the only table that is fully loaded into memory, in every page that is involved! So, it is essential that you keep it as short as you can.

The sitemap form contains the following fields:

Zoglair Sitemap Form (Main)

  • Node
    A unique identifier (no duplicates allowed) of this tree node, as you want it to appear in URLs. It must conform to the node naming rules. Since sitemap nodes are unique, you can link between them without their paths, no matter your chosen URL structure. For example, the node you are viewing right now is “sitemap_”. Other nodes can link to it by writing “[[sitemap_]]”. Zoglair would fill in the proper path automatically. Writing the full path yourself (in this case, “index/documentation/userGuide/acp/database/sitemap_”) not only is redundant, but also will become invalid the moment you either change your URL structure or move this node to a different position!
  • Security Level
    The node's security level (~sevel). This has to do with who is able to read/view it (not edit it). Writing permissions (such as editing) is a table property, not a row one. If you leave this field empty, it means that no sevel is explicitly applied, so the parent node's sevel is in effect.
  • Name
    A (relatively short) name for this node, as you want it to appear in menus, breadcrumbs, and default link text (whenever you do not specify one).
  • Title
    A descriptive title that will be used as a page heading and window caption. In other words, this goes into the “<h1>” and “<title>” HTML tags.
  • Image
    An associated image ID.
  • Phrase ID
    Not used.
  • Container
    A table that provides dynamic content for this node (and its descendants). Data from the container are presented through a mechanism known as drill down. In other words, if you want to automatically categorize, list and display entries from another table (Article, Product, etc), then this is the way to do it.
  • Content Format
    This allows you to change the default format used for displaying content from the table specified in “Container”. If the container is left empty, this field has no use.

Inserting nodes

Sitemap Row Popup Menu You might have noticed that inserting on this table is a bit different than inserting on the other ones. This is due to its tree structure.

First of all, there is no icon on the grid's caption bar. This is because the program needs to know where you want the new node to be inserted. And the only way to know that is to trigger the insertion by clicking on a row (which we call a pivot). For this reason, the insertion link is in the row popup menu.

Second, you will notice a selection box displayed next to the submit button. It offers the option to insert the new node after the pivot, before or under. Inserting a node under another, makes it a child of that.

Finally, the insertion form is populated with pivot's values, instead of empty or default ones. You need to change or clear them, as needed. Remember, when inserting under the pivot, the new node will inherit all values that are left empty. When inserting before or after, it will inherit from the pivot's parent. If the pivot is a first-level node (has no parent), then it will inherit from the top node displayed in the grid, which is named “root”, and it is the parent of all nodes in the sitemap tree. The reason why “root” is not outer-indented is due to space considerations only (to save one indentation level, for the whole tree).

Working with nodes

Due to its data model, insert and delete operations on this table lead to a lot of database writes. If anything happens (such as a server failure) before such an operation completes, then the table will most likely be damaged and there is no way to recover it, unless you restore your database!

As a safety precaution, the program automatically initiates a transaction before one of these operations begins, so that it can restore it, should a query fails. But even this, is not foolproof. So, try to be conscious about what you are doing.

  • It is a good idea to take a backup before making changes to your sitemap.
  • It is not a good idea to change your sitemap with your site open, especially with a lot of visitors online.
  • Use Node Sorter to move nodes around.

The above cautions do not apply to updates of existing nodes (like when you are editing a page). Updates are no problem, because they are atomic.

Deleting a parent node, deletes all descendants too!!!

The four node views

Sitemap nodes are displayed, like almost anything in zoglair, via clips... Specifically, four of them:

  • node
  • nodeCats
  • nodeList
  • nodeItem

The first one is always used. Its job is to display whatever you have written in the “Text” field. The other three are only used (in fact, they are added below node) whenever there is a “Container”, but only one at a time. Which one and when, depends on the active node (the one that the visitor sees):

  • If the active node is not leaf (it has children), then nodeCats is used for displaying its children which act as categories.
  • If the active node is leaf (it has no children) then nodeList is used for listing items from the selected category, unless there is a row parameter in the query string, in which case nodeItem is used to display an item's details.
« Session Udf »
(C) Nick B. Cassos - All Rights Reserved
powered by zoglair
page generated in 39ms (11 queries, 8ms)