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.