views:

42

answers:

1

Currently I have a legacy based non-MVC php framework which I need to update to support a leveling/feature system.

I want to have two modes, a normal mode ( the current mode ) and a level based mode where I control what features are included - low, medium, high tiers.

For example, the low tier will not support google maps, while the medium and high tiers will. The layout varies between the tiers as well, so I have to have a template master file for each tier in addition to my current template.

And there is a difference between the high tier in level mode and the current mode, in that there are certain things included in the high tier, but there are unlimited features in the current mode ( non-level based ).

Currently the system structure is laid out as such:

templates/
    default.php

includes/
    branding.php
    css.php
    js.php
    map.php ( google map )

If you visit index.php or contact.php it just does a require_once APP_PATH . 'templates/default.php'

I know that isn't the most ideal type of environment since it isn't MVC based but that's what I'm stuck with ATM.

The templates/default.php looks something like:

<!doctype html>
<html>
<head>
    <?php include APP_PATH . 'includes/branding.php';
</head>
<body>
    <?php
    switch ( filename ) {
        case 'map':
        include APP_PATH . 'includes/map.php';
    }
    ?>

<?php
include APP_PATH . 'includes/google.php';
?>
</body>
</html>

So a fairly oldschool type of template file.

In order to support the leveling system I suspect I'll have to alter my framework structure to something like..

templates/
    level-0.php
    level-1.php
    level-2.php
    level-3.php

includes/
    branding.php
    css.php
    js.php

Now in my configuration file I'll have to define some constants, such as..

define('LEVEL', 1);
define('TEMPLATE_FILE', APP_PATH . 'templates/level-' . LEVEL . '.php');

default.php becomes level-0.php and for the tier based templates, they are 1, 2, 3 respectively.

So now when I visit a page such as index.php or contact-us.php I would include the TEMPLATE_FILE constant:

require_once TEMPLATE_FILE

- Is this ideal? Are there any drawbacks?

If I go with this method I'll have 4 separate template files and that's fine. So for example the lowest tier won't include the map include while the highest tier will.

Another issue I'm concerned with is sub-branching, is it ok to branch out within the include files? An example is that the lowest tier won't have a favicon. The favicon element is in includes/css.php, so I'll have to branch within that file:

includes/css.php:

<link rel="stylesheet" type="text/css" href="main.css">
<?php if ( LEVEL !== 1 ) { ?>
<link rel="shortcut icon" href="favicon.ico">
<?php } ?>

- This might get a bit messy, but it saves me from duplicating css.php everywhere and having to update 4 instances of it. Is this ideal?

I apologize for the loaded question, appreciate any advice.

+1  A: 

This just looks messy to me, and I wonder why you are going about in this 'leveling' fashion. Because to me it looks like 4 levels of display, 1 being the least, and 4 being the most.

If you are asking what framework to substitute for the one you have, any will work (there are many PHP ones, do a search, my fav is codeigniter.com)

Also looking at the CSS as an example, I am confused why you would bother doing something as insignificant as the favicon (but I can certainly see your example of selective CSS per display level).

But I would just have once CSS file (or broken down into 4 sets: general, lev1,2 etc;) then include and merge into one CSS.

But as you hit the nail on the head, its going toget messy, I would just seperate the content, or better yet, sit down and re-write this whole project, see where the problems are going to be, you seemed to have identified a few yourself, try to write out the project first, then program it once you are happy with the project scope.

Otherwise I would not suggest starting to program without a clear course of action.

Hope that helps

Jakub
1. I prefer Pylons as a web framework, when forced to do PHP I prefer Zend but I'm not looking for a suggestion to do a rewrite of it entirely.... 2. Because it's a very very simple example and demonstrates the problem clearly, I'll apply the same technique to sometimes larger amounts of code 3. The dynamic content is separate from the core templates/"views".. I can't drastically rewrite it because it would differ too much and people who are familiar with it won't be
meder