The ixCMF CMS project – V – main and sub menus

In this blog article I continue with my project to build a CMS based on 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 ixCMF CMS project – III – the object hierarchy
The ixCMF CMS project – IV – objects and their web page counterpart

In the last article we have briefly discussed that we need methods for the web page generators of ixCMF to handle ITX blocks for main and sub menus. When we discussed the required object hierarchy for the CMS application we already indicated that menu generation in the CMS world corresponds more or less to the generation of (detail) object lists for a given master snr key [mnr] in the ixCMF world of MD hierarchies. In this article we have a look at the generation of menus.

Main menus and their contents

We have already defined HMENU objects as the relevant top level objects of a suitable ixCMF MD hierarchy for our CMS. HMENU objects characterize "main menus", which we assume to be present on all web pages of the CMS and which are incorporated into the basic web page layout - i.e. into the ITX templates, which in turn may be derived from templates of a Dreamweaver DWT template hierarchy or from templates of other end user (non PHP) TPL engines.

What is the contents of a main menu? Of course, a list of menu points leading to important web pages. In our case such web pages correspond to PAGE objects of the MD hierarchy. So, the contents of a main menu (HMENU) is basically a list of URL links associated with PAGE objects - or better with their web page counterparts.

What is a URL link for a PAGE object - or better its web page counterpart?

An identified PAGE, SPAGE, SSPAGE object provides information for the generation of an associated web page. Such a web page is the output of a CMS generator program which receives the ixCMF snr key of the object as a GET or POST parameter. A menu link in the CMS is therefore

  • a link to the URL of a standard PHP web page generator program for each of the ixCMF object classes for PAGEs, SPAGEs, SSPAGEs
  • together with a GET or POST parameter(s) to identify the specific ixCMF object (and for control purposes also to identify associated master objects).

Now, what does the generation of a HMENU menu mean in the context of the generation of a web page, e.g. for a PAGE?

Due to the full knowledge of the MD structure in form of the connected MD-Schemata ixCMF can in principal generate the required URLs of the PHP PAGE generator and its different GET/POST parameters as soon as we have a list of "snr"-keys (i.e. of unique identification keys) and other properties of the ixCMF objects corresponding to the links. If we look at a main menu (HMENU) than we would have a given snr-key on the top level of the MD hierarchy. This works as a master key for the list of PAGE objects and respective links in the respective main menu. So a main menu list is restricted to all associated PAGE-objects for a given master key, i.e. a HMENU-snr - it is a detail list for a master key. ixCMF provides of course methods to generate such list.

Streamlining the HMENU generator code

Thus, you may conclude that filling a main menu (HMENU) is nothing more than using appropriate ixCMF methods to generate lists of PAGE objects and their snrs - the latter related to and restricted by a given snr of a HMENU object. Having such a list special methods of the CMS TPL Control Objects would generate the required URL links and fill them in into ITX blocks of standard PAGE, SPAGE and SSPAGE templates. But we have to be a little careful:

From the point of view of the level of the PAGE objects this requires the generation of a list of ixCMF SELF objects restricted by a master snr (= mnr). However, web pages must also be generated for SPAGE and SSPAGE objects. When generating main menus on web pages of SPAGE and SSPAGE objects we talk about list on the relative master (=mas) level or master-2 (=mas-2) level of the MD hierarchy, respectively. I.e., about generating lists of MAS and MAS-2 objects on these levels restricted by m2nr and m3nr identification keys. Of course, ixCMF provides methods to generate different types of lists of MAS and MAS-2 objects - but handling these methods is a little inconvenient regarding the coding for the required generalized "CMS TPL Control Object" class:

The code would have to operate with relative level distances and level case discrimination. But, due to our MD hierarchy, the contents of the main menus is exactly determined by level 1 objects and a snr on level 0, always.

So, one extension of ixCMF which we need is a method to generate a list of objects on a defined MD-level restricted by some snr on its respective master level.

Links to external web pages and "exo" applications

There is more to take care about. The first thing is that you may want to maintain PAGE objects as "dummy" objects with associated links to external applications or web pages. By "external", I mean outside the defined ixCMF MD hierarchy. The external links could lead to well defined ixCMF "exo" applications of a different MD hierarchy or it could lead to pages with whatever URL on the Internet/Intranet.

This leads us to the point that all PAGE, SPAGE and SSPAGE objects should - aside around 100 standard ixCMF fields for control parameters and text/image contents - have the following additional content fields:

  • a boolean flag signaling the use of a special link address
  • a text field to maintain an URL

Jumping over a PAGE by relating it with the address of the first associated SPAGE object page

From other web applications based on ixCMF we know that sometimes customers have the requirement that a main menu point may not lead to a specific PAGE object, but directly to the first SPAGE object associated with it. The web site visitor jumps directly to an SPAGE of a list of SPAGEs associated with a PAGE menu point - without opening a PAGE web page. To handle this requirement a special flag must be added to the list of content fields of PAGE and SPAGE objects.

  • a flag signaling that instead of the link for a PAGE object a link to the first associated SPAGE object should be created.

Menus for SPAGE and SSPAGE objects and respective web pages

Above we have seen that displaying HMENUs means basically displaying a lists of links to web pages for PAGE objects. But the menu structure of a general web page may not only provide HMENUs but shall also reflect lists of links to SPAGE and SSPAGE web pages. As PAGEs are related to HMENU objects SPAGES are related PAGE objects (as master objects).

So, we need to create list of objects on level 2 of the MD hierarchy our CMS application, too. Again one point that requires a new ixCFM-method to create a list of objects on a defined MD level restricted by a given master-snr.

The ITX based structure of menus on the web pages for Page-, SPage- and SSPage-objects

The MD-hierarchy of our defined CMS object classes reflects itself in the menu structure of the three different types of web pages (for PAGE, SPAGE, SSPAGE objects). Fortunately, the menu structure is more or less the same for all type of web pages - at least the algorithm to fill menus, sub- and sub-sub-menus can be designed to be almost the same for all objects of the PAGE-, SPAGE-, SSPAGE-classes.

For a first setup we shall allow for ITX-Blocks

  • for "main menus" (corresponding to HMENU objects)
  • for "main menu points" (corresponding to PAGE objects}

For the following, please remember:
Each object of our hierarchy is identified by an unique ixCMF-"snr", which also defines a corresponding record in the respective database table.

The block for "main menus" may be called "MB_HM_nh" where "nh" represents the ixCMF-"snr" (identification key) of the HMENU object in the corresponding database table.

MB_HM_nh contains an ITX block "MB_PA_nh". Such a block will - beside other things - contain a link where np corresponds to an ixCMF-snr of a PAGE object. Thus, the topmost menu structure found on a PAGE, SPAGE, SSPAGE is something like

<!-- BEGIN MB_HM_nh -->
	<!-- BEGIN MB_PA_nh -->
		....
		<a href="...{PA_np} ...">...{PA_NAME}...</a>
		....
	<!-- END MB_PA_nh -->
<-- END MB_HM_nh -->

The structure given above is a simple clean structure for links to all web pages associated with PAGE objects. The layout of the main menus is done by appropriate CSS rules. Such specific rules may be referred to by the definition of additional ITX block parameters for CSS classes or fixed CSS class names.

Note, that there may be several of such "main menu" blocks - depending on the number of HMENU objects we may have defined in our ixCMF scheme. Therefore, all such blocks should be defined by there names in a unique way. That is the reason why we incorporated the "nh"-number in their names. This is only a caution step: Some versions of PEAR ITX react differently towards the block and placeholder naming. You are on the save side if the placeholder names are different for different blocks.

A limitation of our CMS regarding the end user

Here we find some minor restriction to the flexibility of an end user of our planned CMS:
A change of the number of HMENU objects corresponds to a major change of the general web page layout and its basic ITX templates. Here the flexibility of an end customer is limited; he has to have a HTML-developer that implements any new main menu for him in the template code. Otherwise the definition of a new HMENU object in the the ixCMF based CMS will have no direct effect. This leads to the question whether the INSERT capability should be restricted for end users by setting appropriate rights in ixCMF. The generation and free positioning of main menu blocks by end users will be a step to a more elaborate CMS than we try to realize right now. But the limit is the sky ....

However, there are no real structural restrictions to the number of menu points, i.e. PAGES. The required extension capability of the CMS can easily be realized by CSS rules if the main menu blocks are vertical menu blocks. In case of horizontal menu blocks some intelligence must be implemented on the PHP side or JS/jQuery side to adapt the width of a specific block for the PAGE links with respect to a defined total width of the main menu area OR an extendable multi-line menu structure has to be implemented via CSS.

Preliminary restriction regarding cascading menus for PAGES and SPAGES:

For the time being we do not allow for cascading menus for PAGEs and SPAGEs. That means that all SPAGE menus on a web page have their own separate block which is not directly incorporated inside an ITX block for PAGEs (here inside a "main menu" block). However, a change towards a cascading menu structure of PAGEs and SPAGEs would be an easy extension to our scheme.

So, we further have separate ITX blocks for SPAGES belonging to any PAGE and PAGE-snr chosen by a web page visitor. Note, that a PAGE-snr is also chosen implicitly when you have selected a SPAGE or a SSPAGE object/web-page. In case of a SPAGE the PAGE-snr corresponds to the ixCMF-mnr of the SPAGE object. In case of a SSPAGE the PAGE-snr is equal to the ixCMF-m2nr. Both mnr and m2nr are well defined in case of simple [1:n]-relations between the hierarchy levels due to the features of ixCMF.

Some thinking shows that the cascade restriction actually is not a severe one. You still have the option to build SPAGE menus directly connected to all PAGE menu points. And there, visibility can simply be adjusted by CSS rules and some JS/jQuery wizardry. E.g. in the form that when you hover a PAGE link a connected SPAGE menu will open and you may choose a SPAGE web page directly.

Such a situation requires that a predefined (and maybe cascaded) ITX block for SPAGE menu points must be generated several times and each of the resulting outmost HTML tags must receive a unique HTML ID. Therefore, the web page generators of our CMS must also cover the task of generating unique HTML IDs for very many HTML objects to be generated.

So, what menu structure do we find on the SPAGE/SSPAGE levels? On a PAGE, SPAGE, SSPAGE we basically allow for 2 distinct situations

  • Scenario 1: SPAGE and SSPAGE menus have to be generated for all PAGE links. This is e.g. the case when hovering a PAGE link shall lead to the the display of a (cascaded) SPAGE/SSPAGE menu
  • Scenario 2: There is only 1 general (cascaded) SPAGE/SSPAGE menu which is visible and whose contents is defined by the user chosen PAGE-snr and the chosen SPAGE-snr
  • Scenario 3: a mixture of the two scenarios above

What scenario should hold for a specific web site has to be predefined with the customer. A parameter "spage_scenario" will decide between the steps to be performed in the CMS web page generators. In scenario 1 and 3 the IDs of the generated menus have to be taken care of. To prepare general templates for these scenarios is a bit of a CSS challenge especially when a hovering PAGE menu links shall trigger the visibilities of dependent SPAGE/SSPAGE menus.

In addition we allow

  • for either a cascaded menu structure for SPAGES and SSPAGES
  • OR separate menus for SPAGES and SSPAGES.

We may introduce a general parameter "spage_cascade" to distinguish between the 2 cases in the web page generators of ixCMF. Such a menu situation is already well covered in several ixCMF applications (e.g. for service/sub-service, product/sub-product, team/member structures of web pages).

We limit our considerations in this and future blog articles to one general cascaded SPAGE/SSPAGE menu only. So, lets have a look at the cascaded situation. To discuss a concrete situation we assume that we have a horizontal "main menu" with - lets say - 6 different PAGE menu points and respective links. On a PAGE web page there shall e.g. in addition be a vertical side menu which shows all the SPAGE menu points available for the chosen PAGE-snr. A hovering over a SPAGE point or better a click on a SPAGE menu point (with subsequent change to that SPAGE) shall display an integrated sub menu list of SSPAGE-menu points associated with the SPAGE-snr.

Then, we get something like the following block structure:

<!-- BEGIN MB_SPAGE -->
	<!-- BEGIN MB_SP -->
		<!-- Definition of SPAGE menu points and links -->
		....
		<div id={..{NSP}.. >
			<a id="..{NSP}.." class="{..}" href="...{NP} ..{NSP} ... ">...{SPAGE_NAME} ... </a>
			....
			<!-- BEGIN MB_SSP -->
				...
				<a id="..{NSSP}.." class="{..}" href="...{NP} ..{NSP} ...{NSSP}... ">...{SSPAGE_NAME} ... </a>
				.....
			<!-- END MB_SSP -->
		</div>
		....
	<!-- END MB_SP -->
<!-- END MB_SPAGE -->

[Sorry, if someone expects more details: I do not want to give the precise coding as I do want to earn some money with this project. But I am prepared to give a more detailed, correct and simplified ITX code structure to my customers. Otherwise, somebody has to convince me to make the whole project Opensource.]

Note, that if the web page and the vertical menu are extendable in the vertical direction there is no structural limit to the generation of SPAGE and SSPAGE objects. The generation of SPAGEs and associated SSPAGEs is completely free for the end customer. This makes our little CMS quite flexible : It can cover must of the required scenarios in small and medium big companies as you can easily generate several hundreds of separate pages in a structured way.

The ixCMF CMS project – IV – objects and their web page counterpart

In this blog article I continue with my project to build a CMS based on 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 ixCMF CMS project – III – the object hierarchy

After having defined the object hierarchy for the ixCMF based CMS application I now want to consider some aspects of the web page generation. First, we have to clarify the connection between our assumed ixCMF object classes and related web pages which have to be generated by proper PHP generator programs.

Web page counterparts to PAGE-, SPAGE-, SSPAGE-objects

In the case of our planned CMS, object instances of the ixCMF object classes for PAGEs, SPAGEs and SSPAGEs must and shall define well structured web pages ( - besides other things ... ). Note, that because each ixCMF object is identified by its ixCMF-"snr"-key the same is true for the associated web page.

Such web pages will of course be generated by standard ixCMF generator programs adapted and extended for the purposes of our CMS application. The web page content is - as in all other ixCMF applications - created according to object properties saved in specific database fields.

Eventually, the CMS must provide two basic features:

  • an UI for the maintenance of objects, their contents and their relations via a general ixCMF user interface. Such an interface must also be capable to generate new objects as instances of their ixCMF object classes and handle such objects according to their SCHEMA definitions.
  • generator programs for the automatic generation of web pages for related PAGE, SPAGE, SSPAGE objects on basis of SCHEMA definitions, the user defined object properties and defined generator rules.

These 2 objectives just reflect a special application of what ixCMF provides at its core:

  • Define object classes at different levels of a MD hierarchy,
  • define associated Schemata for the object contents and respective database table fields,
  • use standardized web generator programs that provide a standard ixCMF User Interface for the maintenance of objects, their data and relations
  • AND last but not least build suitable web page generators for object contents that shall be displayed in a defined way on a web page based on ITX templates and ITX blocks.

ixCMF is a simple machinery for maintaining object hierarchies in databases and for defining respective web generators on the basis of methods of appropriate base classes. Which, by chance, provide already most of the basic ingredients required for a small CMS.

ixCMF Template Control Objects

Remember that in ixCMF web pages are created and controlled by so called "TPL Control Objects" (which are derived from a variety of suitable ixCMF base classes). Such TPL Control Objects are the "heart" of the ixCMF web page generator programs.

A TPL Control Object Class

  • can be defined, extended and adapted individually for a specific ixCMF object class and for its related special ITX Templates - in the CMS case for the PAGE, SPAGE, SSPAGE object classes and associated ITX TPLs
  • or it may follow rather simple and general standard generator rules.

In the past the first point allowed for the creation of special and flexible web applications which could seamlessly be integrated into existing web sites of our customers. In the case of our planned CMS the Control Object Classes must, however, be capable to generate complete web pages with user arranged text fields and images AND, of course, link menus from basic ITX templates.

Web page generation for and from ixCMF objects

Thus, the web page generation in our future CMS will be performed by special TPL Control Objects for PAGE, SPAGE, SSPAGE objects. The web page is generated

  • according to a defined Schema for each of our ixCMF object classes (and dependent Schemata of related objects of the MD hierarchy)
  • according to standard rules and methods for the transformation of different special content field types of ixCMF object classes
  • according to geometrical arrangement rules of content blocks on a web page given by the user's choice of a predefined CMS Template (see below)
  • according to the specific contents of the defined "fields" of a distinct PAGE, SPAGE or SSPAGE object - identified by its ixCMF "snr" key
  • AND - and this is typical for a CMS - according to rules for the generation of HMENU menus and PAGE relates sub menus inside a web page with links to other web pages associated with other objects of and within our MD hierarchy.

In any case: In our planned CMS any specific PAGE, SPAGE, SSPAGE object will define an associated well structured web page.

So, one of the more important tasks for the setup of our CMS will be to define rather general CMS web page generators in form of TPL Control Object Classes for both PAGE, SPAGE and SSPAGE objects. Which is an easy task in so far as we have used similar generators before for specialized web applications.

Arrangement of text and image contents
The arrangement of web page content in predefined ways is nothing profoundly new for ixCMF - we have realized similar things before in special web applications for customers. The only difference here is the broader and more general range of text and image content objects and their geometrical placement on the aspired web page partially according to geometrical arrangement rules and partially in free way at user defined coordinates.

For the end user the arrangement of text blocks etc. will therefore partially be ruled by the choice between several offered "CMS Templates" [CMS TPLs] which provide certain predefined geometrical structures of web page contents. A specific predefined CMS Template may e.g. arrange 4 text blocks of variable length (adapted to the text filled in) in such a way that a two column page layout is created where the width of each column is defined by the user as a percentage of the available page area.

One or several predefined ITX templates must therefore work as ixCMF Meta Templates for an extendable variety of "CMS Templates" provided for and to the end user. Nothing really new - but there is still work to be done as each of the aspired CMS Template types must get a proper ITX basis. My approach will be to comprise all reasonable geometrical arrangement in just one ITX TPL with just one associated Control Class that can distinguish between several geometrical layouts and fill appropriate ITX blocks and HTML/CSS definitions.

The end user only chooses between "CMS TPLs" and sets additional parameters - the ixCMF ITX meta templates and their block structure lying behind will be completely transparent for the CMS user. All CMS templates will additionally include the possibility to place some text blocks and images freely at user chosen coordinates. This aspect has already been covered to a certain degree in other ixCMF based web applications.

The choice of a specific CMS TPL for a PAGE, SPAGE or SSPAGE web page is of course saved in a special property of the respective ixCMF object.

Web page links
A typical ixCMF web application defines a web generator for each of the ixCMF object classes. This includes cases where certain objects combine and load other objects of the same MD hierarchy or of external MD hierarchies.

Therefore, in our planned ixCMF based CMS, a menu point represents a link to the URL of a (pretty standardized) PHP web page generator program for each of the ixCMF object classes PAGE, SPAGE, SSPAGE plus an object identifier. A specific object instance of these classes is actually identified by GET/POST parameters attached to the generator URL - among others the most important parameter will be its ixCMF-"snr".

The generation of main menus with links to web pages associated with PAGE objects

Something really new for ixCMF is the generation of main menus which contain links to major web pages of a whole site. More precise: Main menus with links to web pages associated with PAGE objects. Such main menus have to be generated on all web pages of a specific site to be maintained by our CMS.

The main menu structure normally is part of the layout definition of the web pages of a site. That means that we must find a way to generate "main menus" on all ITX templates for PAGE, SPAGE and SSPAGES in a consistent way. The menus will correspond to ITX blocks which contain repeatable blocks for the menu points.

Hovering over main menu points may in addition lead to the display of sub-menus with links to dependent sub-pages. So, the maintenance and generation of main menus is something, for which ixCMF and its generator classes must be equipped with new methods.

Menus with links to web pages for SPAGE and SSPAGE objects

On the web pages created for either PAGES, SPAGES and SSPAGES there may appear distinct or cascaded sub-menus containing links to SPAGES and SSPAGES which are associated with a given PAGE object. Such menus also have to be created and based on special suitable ITX blocks. Methods to create lists of SPAGE and SSPAGE objects have therefore to be provided. Note, that in contrast to the contents of the main menus the contents of SPAGE/SSPAGE menus is dependent on the specific PAGE or SPAGE chosen by the web page visitor.

In the next contribution I shall have a look at the ITX block structures for main and sub menus.

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.