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_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 -->
	<!-- 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.

Eine neue Webpräsenz zu ixCMF für Anwender und Interessierte

Diese Web-Präsenz soll künftig Informationen, Tipps und Tricks zum Content-Managment-Framework "ixCMF" der Fa. Dr. Mönchmeyer - anracon im Web bereitstellen.

Diese Informationen sind einerseits für Kunden gedacht, die bereits von uns erzeugte Pflegesysteme auf der Basis von ixCMF im Einsatz haben. Ihnen möchte wir durch unsere Webseiten einen kleinen zentralen erreichbaren Extra-Service bereitstellen.

Andererseits dient es uns selbst in lockerer Form der Dokumentation und der Diskussion von Weiterentwicklungen und neuen Möglichkeiten ixCMF-basierter Applikationen. Natürlich möchten wir nebenbei auch ein wenig Werbung für unsere Möglichkeiten zur effizienten Erstellung kundenspezifischer Pflege- und Web-Applikationen machen.

Last but not least erfahren über diesen Blog vermutlich auch einige unsere Freunde und früheren Arbeitskollegen endlich, mit was meine Frau und ich uns in den letzten Monaten beruflich so befasst haben.