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.

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.

The ixCMF CMS project – II – setting up the IDEs

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

After having defined the objectives of the project I shall now write about some aspects of the toolset of the project. I shall especially discuss the combination of Eclipse for PHP on Linux systems with Adobe's Dreamweaver on Windows systems and the technical basis for a form of collaboration. This may be interesting for people in general who want to combine pure HTML/CSS efforts via Dreamweaver under Windows with PHP coding efforts by using Eclipse under Linux.

Toolset for the project

Due to the use of PEAR ITX TPLs in our project some initial basic HTML/CSS layout work for a customer web site can always be done completely inside an external HTML/CSS tool, e.g. Adobe's Dreamweaver, whereas the details of the page contents shall later be defined and controlled by the CMS end user.

Technically, my HTML developer provides Dreamweaver Templates (DWTs) from which ITX TPLs are directly derived by simple DWT inheritance mechanisms, the inclusion of defined ITX blocks and placeholders and of course a renaming of the resulting files to "*.tpl". The defined ITX blocks and their placeholders are later on filled by the methods of ixCMF web generator classes on a web server.

In contrast to basic site layout some special TPLs will provide advanced and complicated internal blocks for the CMS maintainable areas of the web page - such as the menus and a large area which the CMS end user controls both with respect to layout and contents. The future ixCMF based CMS UI shall provide web form sheets to define the details of the web page contents and its properties.

Why do we use the PEAR ITX template mechanism ?
There are several reasons why I like to use the PHP based PEAR ITX TPL engine:
It is simple and therefore avoids the inclusion of logic into the template. This is something crucial for me. I absolutely do not like the mixture of PHP and HTML as we for example find it in WordPress. ITX is fast and reliable. It is PHP based - but the TPL definitions require no mixture of PHP and HTML; the TPL definitions of blocks and placeholders can directly be integrated into the pure HTML code.

Why Dreamweaver at all?
The use of PEAR ITX TPLs gives us the chance to use the Dreamweaver DWT engine to master, change and update the elementary design and the layout of a specific website for a customer. The customer itself is afterwards only confronted with the CMS and its user interfaces based on ixCMF.

But one may ask the question why we use Dreamweaver and DWTs at all. Good question, because personally I am not really satisfied with the situation and would prefer a pure PHP approach with e.g. Smarty. The use of Dreamweaver has of course historical reasons - and Dreamweaver once was a really good HTML/CSS tool. The work on a maybe competitive Quanta was stopped some years ago. In my opinion, there is no real open source alternative in sight. HTML/CSS editors like Bluefish do not cover the possibilities of Dreamweaver, yet.

Dreamweaver has a good and simple Template engine which requires no PHP knowledge, but allows for some principles of hierarchical inheritance - although limited. This is something I like - you need no special, complicated knowledge - only some HTML and DWT rules - and hey, you are nevertheless able to change the layout of hundreds of HTML pages in seconds. In our case this is reduced to some basic ITX TPLs - but nevertheless. A pure HTML developer can do this ...

So most of all: I want to use the knowledge of design people who concentrate on HTML, CSS and maybe some JS, only. People, who give a damn about server based development, Linux, Eclipse, PHP and Opensource.

So, as we have to cover a combination of PHP and HTML in this project, we shall use both

  • Eclipse Luna for PHP development on a Linux system to develop and build the whole Web CMS on basis of existing ixCMF classes
  • and Adobe's Dreamweaver on Win7 (in a VMware Workstation) for the definition of the basic HTML/CSS layout of a real test website

Note, however, that in principle one could replace Dreamweaver by any kind of HTML/CSS tool - last not least e.g. by advanced web editors. But, I am lazy and focus on Dreamweaver for the time being. We shall now see, how one can build a technical bridge between Eclipse and Dreamweaver - and still aloow for an ordered development process.

Major step 1:
Technical Project Setup - 2 linked PHP projects on a Linux Eclipse system with a bridge to a Dreamweaver repository

This is a standard procedure for me. The only time consuming obstacle I always meet is the following:

I have to provide a kind of cooperative bridge to Dreamweaver [DW] CS 4, CS 5.5 and CS 6 installations, which are used to work on DWTs that control the layout also of the ITX templates (TPLs). The "Eclipse-to-DW-bridge" shall allow for a defined development workflow.

The solution for such a bridge is of course provided by Samba and the DW Checkin/Checkout mechanisms.

Therefore, from the Eclipse perspective most of the required files in the project will be located on an exported Samba directory on my Linux development system. The Samba folders can on the other side be accessed by my Win7 client (in my case in a VMware Workstation). On my virtual Win 7 I setup Dreamweaver to fill my personal local copy of a central Dreamweaver repository by DW CheckIn and CheckOut mechanisms.

So, what Eclipse uses are local copies of files of a central DW repository placed on a Linux Samba system. The status of the copies is controlled by update and CheckOut/CheckIn mechanisms of Dreamweaver.

The central DW repository is normally located on an Apache test web server in our network. The accessible development folder on the Apache server has a special ACL rights setup under Linux and is also exported by Samba. On the Win7 systems the Apache Samba share is mounted as a local disk. This allows for an easy "local" customization of the DW projects.

Apache, in addition, associates a named virtual web domain in our development network with its folder for the project contents. This domain is accessed with Web browsers for testing.

The Dreamweaver CheckOut status of my personal copies of the DW repository files correspond to "rw-" or "r--" rights of the files in my Samba folder. To get access to these Samba files under Eclipse, I, firstly, setup an Eclipse PHP project "cms_dw". This project is customized to contain the files and folders of the local Samba directory. (Of course Eclipse regards the folder as a normal local folder; it does not care about DW and notices DW's existence only indirectly via the rights settings of the files and "_notes" plus "*.LCK" which one must exclude from the Eclipse PHP build processes - which is easy :-) ).

All folders of this project are furthermore SVN controlled by a Eclipse subversion plugin which connects Eclipse to a SVN server.

Then in a second step I set up a second Eclipse PHP project "cms" - and this is the one I really do development work with. It gets attached to our first project:

The folders of this second PHP project are defined by links to the folders of the "cms_dw" project. The only, however important exceptions are so called "ixCMF Base Classes" which I contribute by links to a separate Eclipse project for ixCMF development. This latter ixCMF project is only available on the Linux Eclipse side as I do not want Dreamweaver users to be able to access these important classes and destroy them by accident. Of course, I have to provide these base classes also to the Dreamweaver colleagues at some points in time - but this is easily done by a specially defined Eclipse "remote export" to the Samba folders of DW repository on the Apache system.

Of course the second Eclipse project gets several Eclipse "Facets" and "Natures". The primary nature is naturally a native "org.eclipse.php.core.PHPNature". However, I allow also for a secondary "Web" nature provided e.g. by the Aptana plugin for Eclipse. Regarding facets: in our case the JavaScript facet is important in addition to the standard PHP facets.

The advantage of this setup is that I can combine any input from the Dreamweaver side with pure PHP and Javascript/jQuery efforts on the Eclipse side.

The Eclipse perspective:
In the start of a project I always DW-CheckOut all PHP files. By doing this they become writable on the Eclipse side and are at the same time protected against changes of the Dreamweaver colleagues. A PHP file I work with on the Eclipse side after a DW checkout is locked against changes by DW users. A DW user will get a warning when he wants to checkout this file from the central DW repository (on the web server). The same is of course valid also for HTML, CSS and JS files.

If I need to see the latest results of the work of my DW colleagues I have to update the present state of the respective files by using either the Dreamweaver Update (read only access in Eclipse) or CheckOut mechanisms (rw access), first.

The Dreamweaver perspective :
If my DW colleague already has performed a DW CheckOut on a file I cannot directly overwrite its contents as DW sets a read only right on the file on my Samba directory. Eclipse then warns me. So, the DW people can protect their work against changes from me. (If you absolutely want to you can of course change the file's access rights in Eclipse - but this is more a matter of discipline).

In short:
This special setup leads to a situation where I can use Dreamweaver files under Eclipse as resources of a special type of an external repository. The workflow from the PHP side may cover both SVN CheckIn/CheckOut aspects and DW CheckIn/CheckOut aspects. Results from the Eclipse PHP side are transferred to the DW side by DW CheckIN mechanisms. Task planning and control on the Eclipse side is of course possible by the Mylyn plugin.

Regarding the transfer and upload onto any test or production web server:
Due to the chosen setup we have the flexibility to perform uploads from either the Eclipse side via FTP/SSH-exports or via Dreamweaver upload mechanisms for its central or other repositoris. So, all in all in a group of working people we can determine who - PHP people or DW people - shall have the final control to deliver files to one or several severs.

Normally, we prefer to deliver files to the test web server by DW CheckIn/CheckOut mechanisms and let the DW people do the FTP export from there to productive servers. To perform the latter task easily and in a controlled way they use a separate additional DW project that couples the contents on the test web server to the remote productive server - this time just with upload and download features and no DW CheckIn/Out.

Thus the DW people can play the role of Gate keepers for all transfers to the productive server. They like it ...

Note, however:
By using defined SSH/FTP export to the test web server from my Eclipse PHP project "cms" I can circumvent Dreamweaver completely. But, as long as all the files I transfer to the test server were DW-CheckedOut, this does not lead to any inconsistencies on the DW side. (It may take some time to understand this).

Nice, isn't it ? Maximum flexibility and still a defined chain of action and cooperation from Eclipse to a DW repository on a test web server.

In the next contribution I shall have a look at the required master-detail hierarchy of ixCMF objects to master and control the basic information for a CMS. See:
The ixCMF CMS project – III – the object hierarchy

Required time for step 1: < 2 hrs.

The ixCMF CMS project – I – some objectives

Eventually, I found some time to start developing and building a CMS for small Websites based upon my own Meta Framework "ixCMF", which I normally use for building web applications. Such applications very often contained CMS like administration elements, too, and of course Web generators to build defined areas of a web page automatically.

However, the features of the web page generators were most of the time secondary in comparison to the general application logic and not adapted to the special logic of a CMS. Furthermore, the Web generators very often produced contents for a very defined and rigid layout of only a part of the web page. The arrangement and positions of the displayed elements like lists, texts or pictures could only in some minor details be influenced by the end customer. This gave us the flexibility to incorporate of web applications like e.g. the presentation of a team and its members seamlessly into an existing web site. This has changed a bit as we had to cover more and more applications and to provide more degrees of freedom to influence the layout of the contents to be displayed.

So, now, I want to use the already existing variety of ixCMF PHP classes to build up a PHP and MySQL based, simple but flexible and dedicated "Web CMS". Its purpose shall be to arrange and maintain the contents of simple hierarchically related Web pages and connect it to definable menu points of menu blocks.

This is a funny endeavor which I always wanted to do but never succeeded due to time limitations.

As it is interesting for myself to see how much effort it takes to build a simple, but flexible CMS with ixCMF I shall start to follow up my efforts in this blog. So, this is going to become a kind of a diary for this special project ... well suited for a blog, as I think.

Introductory remarks and the project objective

Remember that ixCMF allows for a rather complete separation of HTML/CSS coding and PHP coding. This is made possible by the use of Pear ITX templates (ITX TPLs).

The HTML/CSS coding to define the most basic layout elements of a future customer website, whose detailed contents then shall be administered and arranged by the CMS user, can therefore be done by a HTML specialist and Tools outside Eclipse for PHP.

By "most basic" we really mean elementary aspects as

  • page dimensions,
  • the placement of major empty areas (DIVs) for page content and layouts later defined and delivered by the CMS user,
  • fonts and colors
  • and the position and definition of both main menu blocks and potential sub menu and even sub-sub menu blocks (separate or cascaded).

However, the real contents of each web page - i.e. the contents of a rather large CMS editable and maintainable area (a special DIV) - is later on controlled by the CMS user. In my opinion the end user should get control over e.g. the following elements:

  • The definition of new menu points and corresponding web-pages, sub-pages and sub-sub-pages in a 4-fold hierarchy.
  • 4 arrangeable and vertically extensible text blocks - each with a left/right positionable image. The logical and basic geometrical arrangement of the text blocks can be defined by choosing between a variety of so called CMS Templates (CMS TPLs based on ixCMF TPLs and their ITX logic), which shall take control over a large initally empty web page area. Each web page can thus be associated with a chosen variant of an ixCMF TPL defining a content presentation layout. Details of the presentation as e.g. the width of the text blocks should be changeable by the user.
  • 4 additional and freely positionable text blocks with an image each. They allow for a circumvention of the geometric "limitations"" of the defined CMS TPL layout patterns.
  • 4 freely positionable and automatically scalable images. The positioning can be done with respect to defined left upper or right bottom coordinate points of the CMS editable part of the page or relative to the position of a defined text block in a given ixCMF TPL. Note: The positions of the lower left corner of the editable area or the position of a text block are moving targets and depend of course strongly on the contents the user defines. The defined image distances to these reference points are, however, handled precisely by ixCMF.
  • The vertical size of a web page: In my present approach I shall allow for vertically expandable web pages: The vertical size of a web page may therefore both depend on the basic web site layout and on the size and the position and kind of text and image contents defined and generated by the user. The page will adapt its size automatically.
    This feature shall be compatible with the feature that a defined distance to the bottom of a page must be kept constant for some freely positionable elements. This is a bit of a CSS challenge as the bottom of a page may be a moving target through a page maintenance process - but it is solvable.
  • The user shall get the possibility to insert a background image into the CMS editable area. The image can be softened or damped away by an additionally superpositioned layer whose transparency can be controlled.
  • HTML experts can at any time define new CMS TPLs (based on extended ITX TPLs) for the arrangeable text blocks. The HTML developer only has to follow a set of rules for ITX TPL blocks
  • People familiar with ixCMF should be able to easily include special applications - e.g. for job positions, catalog applications, seminars, events ... - into the website and its menus

Quite a list. But most of the topics I have already realized in some special web application. So, I hope, this is going to be more a gathering and integration project than a real "program from scratch" project.

In the next article I shall consider some aspects of the IDEs I am going to use for the project. I shall especially cover a combination of Eclipse for PHP on Linux systems with Adobes Dreamweaver on Windows systems. See:
The ixCMF CMS project – II – setting up the IDEs

Required time for some "theoretical" considerations about the features of my planned CMS: < 2 hrs.

ixCMF im Umfeld einer Simulation von Supply Netzwerken II

In einem früheren Beitrag hatten wir über den anstehenden Einsatz von PHP5 sowie ixCMF in einer "Supply Chain"- oder besser "Supply Netzwerk"-Simulation berichtet. Siehe:

ixCMF im Umfeld einer Simulation von Supply Netzwerken I

In der letzten Woche hatten wir eine interessante Testrunde mit unserem Auftraggeber für das Core-Programm der beauftragten "Supply Netzwerk Simulation". Als Testaufgabe wurde gestellt, für ein Netzwerk mit folgenden charakteristischen Merkmalen eine zeitabhängige Propagationsrechnung durchzuführen:

  • 60 Zeitschritte,
  • ca. 2 * 65 Haupt-Knoten,
  • ca. 2 * 250 unterschiedliche logische Pfadsegmente zwischen den Haupt-Knoten,
  • ca. 19000 individuelle logische Pfade durch das Netz,
  • logische Tiefe der Knotenstruktur > 9,
  • 3 zu propagierende Größen,
  • ca. 80 Zeitschritte

Auf einem Laptop mit Opensuse 12.3, Apache2 mit PHP 5.4, MariaDB und einer Hardware mit I7 3632 Quad Mobile Prozessor, 16 GB RAM und einer schnellen SSD haben wir

  • die logische Struktur-Analyse des Netzwerks samt einer Analyse aller möglichen Pfade in 15 Sekunden
  • und den eigentlichen Simulationslauf auf dem 3-dimensionalen Netz-Zeit-Gitter in unter 3 Sekunden

fehlerfrei bewältigt.

Dabei wurden im Schnitt nur zwei Prozessorcores belastet. Der Speicherbedarf des PHP-Programms betrug ca. 60 MB. Bzgl. der Datenbanktransaktionen, die zur Abspeicherung der berechneten Daten erforderlich sind, konnten wir zeigen, dass die SSD auf einem Laptop bereits eine Peak-Performance im Bereich von mehreren Tausend (einfachen) Transaktionen per Sek. ermöglicht. Auf einer anderen über den zugehörigen Linux Host gut gepufferten virtuellen LAMP-Maschine mit nur einem einzigen CPU Core (Quad 9950 auf dem Host / Raid-System mit virtio-Zugriff der KVM-Guests) haben wir entsprechend ebenfalls Insert-Raten im Bereich von über 20K Inserts pro Sekunde bei kleinen Datengrößen pro Record gemessen.


Dies alles hat uns und unserem Auftraggeber gezeigt, dass wir auf dem richtigen Weg sind. Bereits ein nur ansatzweise optimiertes PHP-Programm bietet auf aktueller Hardware genügend Perfomance-Reserven nicht nur für einzelne sondern ganze Ketten von vielen sukzessiven Simulationsläufen. Zwischenzeitliche Kritik, das ganze System sei allein aus Performance-Gründen in Java zu entwickeln, konnten wir dadurch weitgehend entkräften. Die eigentlich zu stellende Frage wäre aus unserer Sicht zudem eher die gewesen, ob man bestimmte Komponenten des Core-Systems nicht besser hätte in C (mit embedded SQL) darstellen sollen.

Nächste Schritte bestehen nun in einer Erweiterung der im Simulationslauf zu lösenden Aufgaben und einer Erweiterung des Transportes der zu verfolgenden Größen. Für das zu entwickelnde User-Interface zur Kontrolle einer Sequenz von Simulationsläufen wird ixCMF in wachsendem Umfang zum Einsatz kommen.

ixCMF im Umfeld einer Simulation von Supply Netzwerken I

Im Auftrag eines Supply Chain Beraters entwickelt die Fa. anracon zur Zeit Prototypen zur Durchführung von logischen und statistischen Analysen von Supply Netzwerken und zur zeitabhängigen Simulation solcher Netze.

Komplexe Netzwerke in mehreren Dimensionen

"Supply Chain"-Prozesse entfalten sich heute weniger als einzelne lineare Ketten, sondern als Prozesse in komplexen Netzwerke aus verzahnten Pfadsegmenten und verarbeitenden Einheiten für die Transformation von Zwischenprodukten. Dabei spielen die Zeitabhängigkeit der Erzeugung von Zwischen- und Endprodukten sowie die Zeitabhängigkeit des zugehörigen Transportes eine entscheidende Rolle.

Die Rückberechnung von Konsequenzen aus Kunden-Anforderungen auf die zeitgerechte Produktion im Supply Netzwerk erfordert zeitabhängige Simulationen von Netzen, die nur im Ein- und Ausgangsbereich baumartigen Strukturen ähneln. Im Hauptbereich entsprechen moderne Supply Netze vielmehr voll entwickelten Netzwerken mit Knoten, die auf vielfältige Weise miteinander verbundenen sein können.

Rückkopplungen erzeugter Zwischen-Produkte in bestimmte verarbeitende Knoten verkomplizieren die logische Struktur und heben "natürlich" erscheinende geometrische Knotenanordnungen, die sich auf die produzierenden Einheiten beziehen, hinsichtlich einer strukturellen, logischen Ordnung materialabhängiger Pfade auf. Den gleichen Effekt haben produktabhängige Zeitverschiebungen. Die logische Abfolgestruktur entspricht nicht mehr der physikalischen Knotenanordnung von Produktionseinheiten sondern tiefer liegenden Ordnungsstrukturen, deren Knoten Punkte einer komplexen, hoch entwickelten mehrdimensionalen Netzstruktur sind.

Entwicklung des Core-Algorithmus

Dr. Ralph Mönchmeyer ist z.Z. maßgeblich an der Entwicklung eines Core-Algorithmus zur logischen Analyse solcher Netzwerke, zur Simulation dynamischer Gleichgewichte zu vorgegebenen Produktionsniveaus und zur Simulation der Auswirkungen zeitlich veränderlicher Kundenanforderungen auf das Netz beteiligt. Das gesamte System wird zwar datenbankgestützt laufen; wesentliche Operationen werden jedoch auf komplexen Array-Strukturen im Speicher erfolgen. Hier kommt einerseits die Erfahrung von Dr. Mönchmeyer im Umgang mit komplexen numerischen Simulationen physikalischer Systeme als auch die Erfahrung mit weborientierten Spachen wie PHP zum Tragen.

Einsatz von PHP und ixCMF

Ungewöhnlich ist in diesem Zusammenhang der Einsatz von PHP 5. Sieht man als Ziel aber eine Software, die im Web später ggf. als SaaS angeboten werden soll, so bekommt diese Anforderung Sinn. Ferner spielen die guten Möglichkeiten von PHP zur Anbindung an Datenbanken, zur Darstellung von Webservices sowie zur Erzeugung von Grafiken eine Rolle.

Da PHP eine rel. "langsame" Sprache ist, ist auf Programmoptimierung und Performance großen Wert zu legen: Einfache realistische Netze enthalten bereits mehrere zehn-tausend unterschiedlicher Pfade zwischen Ausgangs- und Eingangsknoten. Erste Simulationsrechnungen zeigen, dass die erforderlichen Zeiten zur Analyse und Simulation auch ohne künstliches Threading und Parallelisierung auf Webservern bereits im gewünschten Zielkorridor liegen.

Was hat das Ganze mit ixCMF zu tun?

Bzgl. der Kernalgorithmen fast nichts. ixCMF hilft jedoch bereits jetzt bei der strukturierten Verwaltung von Parameter- und Strukturtabellen und der webbasierten Darstellung von Ergebnistabellen. Ferner wird die Veränderung von Schlüsselwerten für Vergleichssimulationen erleichtert.

In späteren Ausbaustadien wird ixCMF jedoch eine Rolle bei der Erzeugung kundenspezifischer Webseiten und des Aufbaus eines generellen User-Interfaces zur Steuerung von Simulationsläufen spielen.

Unabhängig davon freuen wir uns, dass ixCMF schon heute die Handhabung der komplexen Tabellen, in denen die Struktur und Parameter des Supply Netzes erfasst werden, unterstützen kann.

Erneuerung der Applikation „Stellenanzeigen“

Seit der Version 1.0 des ixCMF-Frameworks gibt es eine Applikation, mit der mittelständische Unternehmen auf einfache Weise Stellenanzeigen in ihre Website integrieren können. Diese Applikation wird z.Z. für einen Kunden erneuert und an das aktuelle Framework 4.0 angepasst. Dabei wird u.a. dafür gesorgt, dass die Stellen Niederlassungen (in anderen Orten) zugeordnet werden können. In der Web-Anzeige wird ein entsprechender Filter nach der Niederlassung angeboten.

Kennzeichen der bisherigen Applikation

Die Applikation erlaubt das Erfassen bestimmter charakteristischer Felder zur Beschreibung der Stelle wie etwa :

Berufsgruppe, erforderliche Qualifikation, ab wann, zeitl. Umfang, Beschreibung, Ansprechpartner ... etc...

Zu den erfassten Inhalten verschiedener Stellenangebote werden folgende Arten von Web-Seiten generiert:

  • eine listenartige Übersicht zu allen angebotenen Stellen
  • eine Einzelseite zur Darstellung einer aus der Liste ausgewählten Position
  • eine generierte und ausdruckbare PDF-Datei mit allen erforderlichen Informationen

Die Erfassungsmasken entsprechen dabei den Masken des ixCMF des FW 1.0. Die Stellenapplikation kann an das ixCMF-User- und Rechte-System angebunden werden.

Bislang konnten nur Stellen-Anzeigen für genau zwei unterschiedliche Niederlassungen erfasst werden.

Kennzeichen der überarbeiteten Applikation

Die Überarbeitung erfolgt in folgenden größeren Schritten:

Zwischenlösung (bis ca. 20.08.)

  • Nutzung der Pflege-Masken (Stretch-Layout), Funktionalitäten und Webseitengeneratoren des FW 4.0
  • Technische Anpassung der Schemata und Datenbank-Tabellen an das FW 4.0. Damit wird die spätere Erfassung weiterer Freitextfelder und von Bildern vorbereitet.
  • Künstliche Einschränkung der Erfassungsfelder auf das bisherige Spektrum.
  • Aufbau einer vollständigen verzahnten Master-Detail-Hierarchie aus drei Applikationen: Für die Erfassung/Nutzung von Orten und Niederlassungen sowie die eigentliche Stellenapplikation. Damit können Kunden ihre Stellen vorhandenen Niederlassungen anderer ixCMF-Anwendungen zuordnen oder in einer Stand Alone Umgebung schnell Orte und Niederlassungen erfassen und dann den Stellen zuordnen.
  • Filter nach der Niederlassung in den Pflegemasken der Stellenbearbeitung
  • Filter nach der Niederlassung in den generierten, öffentlich zugänglichen Webseiten
  • Herstellung der Lauffähigkeit in älteren Umgebungen ixCMF V2.0 oder V3.0.
  • Ablösung der bisherigen Anwendung durch die Zwischenlösung.

Standard-Kundenlösung (bis ca. 30.09.)

  • Erweiterung der FPDF-basierten PDF-Generatoren zur Behandlung und Formatierung von Aufzählungen in erfassten Texten. Dabei werden Blocksatz-Darstellungen inkl. evtl. vorhandener Bold- und Italic-Formatierungen beachtet. Letzteres ist in FPDF ja ein grundsätzliches Problem. Hiermit werden die bisherigen Formatierungsmöglichkeiten der PDF-Generatoren des IxCMF V4.0 grundsätzlich erweitert.
  • Erweiterung der PDF-Generatoren für Stellen zur Behandlung erfasster Bilder, die Freitext-Feldern zugeordnet sind.
  • Freischaltung der Erfassung der Standard-Freitext-Felder mit Bildern des FW 4.0.
  • Erfassung von frei positionierbaren Bildern für die Stellenpräsentation auf den Webseiten zur Einzelansicht einer Webseite. (Diese Bilder werden im PDF ignoriert.)
  • Erfassung von Layout-Varianten für die Webseiten zur Darstellung einer einzelnen Stelle. (Layout-Varianten werden im PDF ignoriert).

Erweiterte Kundenlösung (bis ca. 30.11.)

  • Automatische Erfassung neuer Berufsgruppen in einer Datenbanktabelle / Auswahl in der Pflege per Select-Box
  • Kalender-Widget zur Erfassung von Datumsinformationen
  • Berücksichtigung der drei Basislayouts für die Web-Einzelpräsentation in Form von drei Varianten der PDF-Generatoren.
  • Berücksichtigung von 3 frei positionierten Bildern im PDF.


Es handelt sich um ein mittleres PHP5-Projekt, mit dem die bisherige Stellenapplikation erneuert, auf mehrere Niederlassungen erweitert und um attraktive Features erweitert wird. Die kommenden zwei Anwendungsvarianten können im Verbund mit anderen ixCMF-Anwendungen betrieben werden oder sie lassen sich durch uns als Einzelapplikationen in vorhandene statische oder PHP-basierte Websites integrieren. Voraussetzungen sind PHP 5.1 oder höher, MySQL 5, die Basisklassen des FW 4.0 und applikationsspezifische Dateien.

Geänderte BB-Hyperlink-Behandlung in ixCMF

Auf Kundenwunsch behandeln wir Hyperlinks, die über das BB-Code-Panel in Textboxen eingepflegt werden, künftig wie folgt:

  1. Fall 1 - Link zu externer Domaine: Gibt der Anwender die Link-Adresse mit einem Standard-Vorspann der Art "http://" oder "https://" oder "www" oder ohne Vorspann ein, so wird untersucht, ob die Domaine der Link-Adresse mit der Domaine der eigenen Website übereinstimmt. Ist das nicht der Fall - also handelt es sich um einen externen Link - so wird der Link so angelegt, dass die korrespondierende Webseite in einem neuen Browser-Tab oder einem neuen Browser-Fenster geöffnet wird - je nach Browser-Einstellung des Besuchers.
  2. Fall 2 - Link zur eigenen Domaine: Gibt der Anwender die Link-Adresse mit einem Vorspann der Art "http://" oder "https://" oder "www" oder ohne Vorspann ein, so wird untersucht, ob die Domaine der Link-Adresse mit der Domaine der eigenen Website übereinstimmt. Ist das der Fall - also handelt es sich um einen Link auf eine Seite der eigenen Domaine - so wird der Link so angelegt, dass die korrespondierende Web-Seite im aktuell geöffneten Browserfenster oder Browser-Tab angezeigt wird.
  3. Fall 3 - Relativer Pfad zur eigenen Domaine: Gibt der Anwender einen relativen Pfad innerhalb der eigenen Domaine mittels eines einleitenden "./" oder "../" ein, so wird der Link so angelegt, dass die korrespondierende Web-Seite im aktuell geöffneten Browser-Fenster oder Browser-Tab angezeigt wird.

Hinsichtlich des BB-Code-Checkers gilt:

Ein <A>-Tag wird vom ixCMF-BB-Checker bis auf weiteres als ein Tag behandelt, das keine weiteren inneren Tags beinhalten darf.
Will man einen Fett- oder Kursiv-Formatierung des Link-Namens erreichen, so muss das <B>- oder das <I>-Tag um das <A>-Tag herum angelegt werden.
Ein <A>-Tag darf aber innerhalb aller anderen bislang erlaubten Tags angelegt werden.

Das BB-Code-Script der Pflegemasken für die Version 4 wurde entsprechend modifiziert. Die betroffenen Kunden wurden damit versorgt.

Bug im BB-Code-Script behoben

Unter bestimmten Umständen stolperte die "Checker"-Funktion des aktuellen BB-Code-Scripts über einen Fehler im Zusammenhang mit der Analyse innerer <I>-Tags. Das verhinderte u.a. eine regelgerechte Analyse von <UL>- und <_I>-Tags, wenn zuvor ein inneres <I>-Tag im Text auftauchte.

Dieser Fehler betrifft die Versionen 4 und 5 und ist heute behoben worden. Ein Update bei den betroffenen Kunden ist erfolgt.