views:

47

answers:

2

Hi there,

I am programming in an old fashion - still using functions and not classes. For example, something basic I do when creating a basic template for a site is put the header and footer in a function like so in a file called functions.php

<?php
//header
function outline_start() {

echo '
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"&gt;
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr" lang="en-US">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>my site</title>  
</head>
<body>
';

}

//footer
function outline_end() {
echo '
</body></html>
';

}
?>

Then in another file, like index.php I'd do the following:

<?php

include(functions.php);

outline_start();

echo 'hello world';

outline_end();

?>

This can pose issues security wise with needing to use global variables I've been told and generally is bad practice - right?

What is the best practice?

+2  A: 

Best practices can be best determined by the team you're working with. The way I see it, you've got one of two options:

You can prefix your functions into a sort of "the functions with these prefixes are for these operations". This is similar to what PHP has been doing for a while, i.e. db_connect() and db_query(). But really, this is very similar to exactly what you already have (outline_start() and outline_end()).

If you want to encapsulate this in a class, you can:

class Outline {
  function Start() {
     //Code to echo here.  Or, if you prefer, return the string.
  }

  function End() {
     //Code to echo here.  Or, if you prefer, return the string.
  }
}

However, most people would recommend you use a view engine approach, or at the very least, a php_include of your header and footer. It is widely accepted that you do your best to keep the HTML out of your PHP code. It makes it easy for CSS, styling, and JS later, if you're into that sort of stuff. Therefore, if the purpose of your PHP functions is to really just return static HTML, just stick it in another file and don't worry about trying to PHP5 it up.

villecoder
i see, like include(header.php). Rather use classes for actual db related stuff and processes?
KeenLearner
That's what I normally do, KeenLearner. The idea that your PHP is doing logic related stuff rather than returning just HTML.
villecoder
+1  A: 

Your title mentions 'classes' so I'm guessing you're interested in comparing an OOP (object oriented programming) concept to your function based 'template'.

It's probably not going to be that easy to compare the two without some basic understand of OOP. Assuming you have the foundation, an object based template system would have a 'view' object that handled outputting the template. There would be methods used to assign variables and even assign the templates themselves.

<?php
//make the template variable name contain the value 'John'
$view->assign('name', 'John'); 

//make color contain the value of $color
$view->assign('color', $color);

//use the 'user' template
$view->setScript('user');

//display the template
$view->render();
?> 

Now the template itself may use some kind of special template language (like Smarty) or perhaps just use native PHP (like Zend_View). It should allow the inclusion of sub-templates, either by assigning the output of the sub-template to the main template (like it's just another template variable), allowing templates to include other templates, or use some kind of master layout to include the different content sections.

When it comes down to it, most OOP template implementations will 'include' the common sections, wich may be considered similar to the approach you use now. However, the main difference is that OOP techniques will (or should?) tend to move you away from mixing your presentation layer (the HTML) in with all the rest of your code.

But there are many varied OOP template engines - take a look at some of them and see what they offer. You may also want to take a look at the mVC (Model-View-Controller) design pattern.

Tim Lytle