The ixCMF CMS project – III – the object hierarchy

In this blog article I continue with my project to build a CMS with ixCMF classes. For the first articles of this series see:
The ixCMF CMS project – I – some objectives
The ixCMF CMS project – II – setting up the IDEs

The aspired CMS shall work as a special implementation of a hierarchical ixCMF Web application. By "hierarchical" I refer to the ability of ixCMF

  • to maintain and control a series of interconnected Master-Detail [MD] object levels and provide a suitable UI for this purpose
  • plus to generate web page content for such interconnected MD objects - as e.g. the web display of a Master object with a list of associated detail records.

Thus, the basic question at the beginning of our work is:

What kind of MD object hierarchy do we need to govern the CMS logic ?

In this blog article we shall briefly discuss my main considerations for an answer.

Major step 2:
Defining a hierarchy for menus and web pages

Any reasonable web page requires some menus to guide the user interaction. At least: Some main menus. E.g. a horizontal menu or a vertical menu with menu points. Very often you find several independent menus on one web page. Each menu point of a given menu will lead to a singular and distinct web page.

Sometimes a menu point may in addition also directly lead to the first a variety of pages whose links are arranged in dependent sub menus. And so on. Thus a web site may in general define a type of hierarchy of menu points and associated web pages.

  • Main menus - we shall abbreviate a menu as an object by "HMENU" later on /li>
  • Menu points - which lead to a certain web "PAGE" with/without a sub menu. Thus each "Page" may open a new individual sub level hierarchy - i.e. of sub and sub-sub pages.
  • Sub menus and corresponding sub pages - "SPAGE"s - of a PAGE
  • Sub-Sub menus and corresponding sub sub pages - "SSPAGE"s - of a SPAGE.

Note: A PAGE (menu point) may also lead to web pages of a specific external ixCMF application (a so called "exo application") which controls its own menus. This aspect has somehow to be covered in our planned CMS.

If you now abstract from the menus and ask for ixCMF objects which should internally be represented in the CMS you arrive at the following hierarchy of objects with cascaded 1:n relations to each other:

  • Hierarchy level 0: HMENU ( = main menu block) - with [1:n]-relation to PAGE objects
  • Hierarchy level 1: PAGE - with [1:n]-relation to SPAGE objects
  • Hierarchy level 2: SPAGE - with [1:n]-relation to SSPAGE objects
  • Hierarchy level 3: SSPAGE - end of hierarchy

Note 1: Menu points are equal to objects representing the properties of a web page

Actually, we consider a menu point to be special property of an object representing a complete web page with all typically associated properties (which usually are more than 100). SPAGE and SSPAGE objects are directly derived from PAGE objects - they have similar properties and methods regarding the page layout. However, they contain of course different information regarding the level structure.

Note 2: The first level is special one and refers to special ITX TPL block definitions

The first level is distinguished from the other levels because an object for a main menu block only has to be defined with some elementary properties (and corresponding database fields). It does not require the manifold of properties to maintain and generate contents on a web page. However, for PAGE, SPAGE, SSPAGE we talk about over 100 properties to maintain contents. We shall have a look at this in subsequent articles. The HMENU objects inserted and maintained by the methods of the ixCMF hierarchy control objects are directly related to menus included as ITX blocks in the HTML/CSS definition of a DWT TPL for the customer specific web page layout.

Note 3: Hierarchy control is supplied freely by ixCMF control methods

Without going into details you may further note the big advantage ixCMF gives us freely:
In the ITX-based TPL approach of ixCMF, you do not need a special dedicated menu administration. The basic menu layout is defined in the ITX TPLs. Their ITX blocks have to follow certain naming rules associated with the hierarchy given above. In addition the main menus have to be represented on a top level object layer with a top level Schema of an ixCMF MD hierarchy. The rest is done by PAGE-like objects and their Schema representations. That's all.
The complete ixCMF MD object hierarchy - once established - alone defines and provides all and everything needed with respect to the generation of menu points and associated web pages as long as you have interfaces and internal methods to control the object hierarchy completely. Which is the case in ixCMF:
ixCMF contains Base Classes to cover hierarchical [1:n]-relations plus at least one [n:m]-relation over several levels. ixCMF provides interfaces, Master-Detail-Views and Controls to maintain related objects on such hierarchy levels. The user can switch between the levels in a controlled and logical way.

Thus, menu administration and menu point administration from the ixCMF point of view is just a special case of MD hierarchy administration and maintenance plus a suitable definition of ITX blocks in a basic site template.

The internal representation of discussed the 4-fold object hierarchy in ixCMF controls all other aspects - especially the relations between the levels and thereby also what has to appear in which menu, sub menu or sub-sub menu. ixCMF V4 furthermore provides classes to generate cascaded menus for 2 adjacent levels or 2 separate menus for 2 adjacent levels.

Note in addition that we have limited the number of hierarchical levels somewhat artificially by 4 levels. This seems a reasonable assumption regarding the depth of a typical smaller web site and its contents. Even with this limitation we could easily master and control a range of several hundred pages.

In the next article we shall discuss some aspects of the relation between ixCMF objects in a MD hierarchy and the generation of associated web pages. See:
The ixCMF CMS project – IV – objects and their web page counterpart

Required time for step 2: ca. 8 hrs of theoretical conceptional work by analyzing the requirements of typical smaller web sites and comparing their requirements to ixCMF features. Actually I have thought about these points several times in the past - and eventually limited myself to the most simple approach.