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.