Posts Tagged conventions

Posted on Uncategorised

Themes and Skins

When planning the system that I am currently working on, I had two main goals. The latter being that I wanted to be able to easily and profoundly change the way it was displayed. The former is unrelated to this blok.

To do this, I made use of a combination of themes and skins, although these are probably poorly chosen names (it was late).

A Theme defines the HTML used. It can also include it’s own CSS files and images as appropriate. Basically, you can do everything that you can do with a skin with themes. A theme has several required files, and a few special files, but can can contain anything in addition to those.
The special files in a theme are files that override the default HTML that a module uses. They take the form of [module_name]-[file_name]. For example, to override the file product.html in the products module, you need only add a file named products-product.html to your theme directory.

A skin is basically the CSS that is automagically included in theme. They also have required files, special files, and can contain additional files. The required files are ones like style.css (the main style sheet for the skin) and screenshot.jpg (which is displayed to help the user pick a skin).
Special skin files are browser specific CSS files, files that will be included with conditional comments if they exist, and files that will be included by PHP according to the browser data apache gives it. This is to allow skins to work in most browsers with some level of ease.
The skin directory is a good place to include an images directory (as css files reference images relative to their location).

Both themes and skins make use of data holders. Data holders are character sequences that mark where in the HTML or CSS file data should be inserted. They take the form: <!–#data_name–>.

So, that was my method for allowing me to easily change the way the data is displayed. It seems to work pretty well so far, but I have only made one theme and one skin as yet :P.

 

Posted on Uncategorised

appearance and conventions

I don’t like HTML in PHP. Or, worse yet, PHP in HTML. Now, obviously this is a matter of preference and there are benefits and difficulties that accompany each method.

Adding PHP to HTML is quick and easy. The main problems being that it can then be difficult to find your PHP in the mess of HTML, especially if your HTML isn’t clean — and that the idea of trying to implement a system of any complexity in this manner disgusts me. Maybe not a problem for you, but certainly one that prevents me from using this method as much as possible.

Adding HTML to PHP is the middle ground. It is easy, and good for initial testing as you only have to edit the one file that contains both the PHP and the HTML it outputs. But, again, it is not a method that I would choose for a final product, although it is a method that I would use under the right constraints. The problem with this method is that anyone who wishes to change the way the output is formatted will have to edit the PHP file itself. This is less of a problem if it is you who is editing it than if it is someone who is unfamiliar with the system, but still there is the possibility that even a simple change in formatting can temporarily break everything – typos are more common than a cold. This is also less of a problem if the HTML you use to format your output is nice, and can be styled with an included CSS file.

Preferably, interface and function would be kept entirely separate – or at least as much so as possible. Of course, doing that in a way that is both general and flexible is understandably more difficult. Separating interface and function allows for easy switching of themes and skins (that can be very different, visually) and, at least to me, is more elegant. (By which I mean, it doesn’t make me feel sick)

My next blog should explain the method I used to allow for this in the project I am currently working on.