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.