[PHP]I need to make a decision

My game, thamob.nl, uses frames atm.
I'm still just not sure of what I should use.. frames, or include (with php and $_GET).
Frames are giving a quite hard time atm, and $_GET seems simpler..

So what'd you say?
Frames or $_GET include?

P.S:
I just thought of another alternative: a header.php and footer.php, just place the content inbetween.

I would run with header, footer and middle content, like so:

PHP Code:

---

<?php
include_once('head_file.phtml')
if(isset($_GET['page']))
{
    if(file_exists($_GET['page'] . '.php'))
    {
        include_once($_GET['page'] . '.php');
    }
    else
    {
        include_once('index.php');
    }
}
else
{
    include_once('index.php');
}
include_once('foot_file.phtml');
?>

---

Ths is how I would do it, code a layout in (x)html then include php files on the places they are needed.

Quote:

---

Originally Posted by Pieman

Ths is how I would do it, code a layout in (x)html then include php files on the places they are needed.

---

Extra note on this for Elite, if you get an (x)html valid template and you plan to keep it (x)html value, be sure to use <p> around your sentencing etc.

Quote:

---

Originally Posted by Pieman

Ths is how I would do it, code a layout in (x)html then include php files on the places they are needed.

---

Or slightly more elaborate: use a template handler and a page handler, create templates for the header and footer and central content and let your pagehandler always output the header, content and footer in that order.

The framework I developped for the company I work for works like that. Simplified:

PHP Code:

---

$pageHandler = new PageHandler;
$pageHandler -> setContentTemplate('directory/template.tpl');
$pageHandler -> showPage(); 


---

The pageHandler object is in reality a static reference in a global context object using a factory pattern, effectively meaning that:

1. It can be called from any function like this:

PHP Code:

---

function someMethod () {
  global $context;
  $context -> pageHandler -> setContentTemplate('directory/template.tpl');
} 


---

2. There is always only one pageHandler, so you can assign a default template to it and later on assign a specific (content) template for it.

Quote:

---

Originally Posted by FragFrog

Or slightly more elaborate: use a template handler and a page handler, create templates for the header and footer and central content and let your pagehandler always output the header, content and footer in that order.

The framework I developped for the company I work for works like that. Simplified:

PHP Code:

---

$pageHandler = new PageHandler;
$pageHandler -> setContentTemplate('directory/template.tpl');
$pageHandler -> showPage(); 


---

The pageHandler object is in reality a static reference in a global context object using a factory pattern, effectively meaning that:

1. It can be called from any function like this:

PHP Code:

---

function someMethod () {
  global $context;
  $context -> pageHandler -> setContentTemplate('directory/template.tpl');
} 


---

2. There is always only one pageHandler, so you can assign a default template to it and later on assign a specific (content) template for it.

---

Wouldn't a singleton pattern serve template handlers(singular) better? Also, using template handler with fixed order disables an option for changing the template from the content context itself.
A simple yet more elegant solution is to make a template file which echoes $content, for example, which was populated by the content script before the actual layout was rendered using output buffering, allowing the content to change the layout.

Quote:

---

Originally Posted by Vineyard

Wouldn't a singleton pattern serve template handlers(singular) better? Also, using template handler with fixed order disables an option for changing the template from the content context itself.
A simple yet more elegant solution is to make a template file which echoes $content, for example, which was populated by the content script before the actual layout was rendered using output buffering, allowing the content to change the layout.

---

Much better to use template profiler with on-the-fly rendering.

Quote:

---

Originally Posted by fook3d

I would run with header, footer and middle content, like so:

PHP Code:

---

<?php
include_once('head_file.phtml')
if(isset($_GET['page']))
{
    if(file_exists($_GET['page'] . '.php'))
    {
        include_once($_GET['page'] . '.php');
    }
    else
    {
        include_once('index.php');
    }
}
else
{
    include_once('index.php');
}
include_once('foot_file.phtml');
?>

---

---

Imagine if that GET request would be like ../../ or something like that? Not good. Always use at least

PHP Code:

---

if(eregi("\.\./", $_GET["page"]))
   throw new Exception("Hacking attempt detected"); 


---

and put your logic after that.

Quote:

---

Originally Posted by Vineyard

A simple yet more elegant solution is to make a template file which echoes $content, for example, which was populated by the content script before the actual layout was rendered using output buffering, allowing the content to change the layout.

---

No, because that implies that $content contains HTML. That in turn implies mixing your business logic with display logic which goes right against any good coding practicse you might be adhering to.

Instead, if you'd actually understood my example, a different template will have a different layout already. Almost every site however will still have a header and footer (and usually menu) that need to be displayed surrounding that actual content template. The content is still pre-rendered without using something as inherently ugly, slow and error prone as output buffering, loaded into the template handler and only then shown. This means that in the template we can have certain directives to influence how the data is displayed:

Code:

---

{if $loggedIn}
  Hello {$username}!
{else}
  Hello guest!
{/if}

---

Just like you would let your PHP screw around with your output buffer, only in this case it's actually seperated from the PHP code. There are some basic smarty tags for making (minor) modifications in your display depending on your data.

Concerning singletons: if you'd actually understood what I wrote you would know that the factory already creates static object references which makes them in practice behave the exact same way as singletons, though without being predefined as a normal singleton is. It's the combination of the two patterns that make it work beautifully, if you think 'one is better than the other' you need to start reading better books.