views:

410

answers:

6

What is better...make classes specially for rendering html, sth. like this:

class IndexHTML {
    public $doctype = "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\"&gt;";
    public $title = "<title>MICE</title>"; //title of document
    public $contentType = "<meta http-equiv=\"Content-Type\" content=\"text/html;charset=utf-8\" />";
    public $contentStyleType = "<meta http-equiv=\"Content-Style-Type\" content=\"text/css\" />";
    public $jsSrc = "<script type=\"text/javascript\" src=\"main.js\"></script>"; //your javascript files included
    public $css = "<link rel=\"stylesheet\" type=\"text/css\" href=\"style.css\" />"; //your css files included

    function html_head(){
        echo $this->doctype."<html><head>";
        echo $this->title,$this->contentType,$this->contentStyleType,$this->jsSrc,$this->css;
        echo "</head>";
        require_once("classes.php"); //require additional needed scripts
    }
}

or is it better to write seperate files like head.html (with only head necessary tags), menu.html, footer.html etc and then write only :

class IndexHTML {    
    function html_head(){   
        require_once("head.html");       
    }
}

I'm new in PHP and try to learn the proper way of dealing with things.

EDIT:Seperate files are better for maintainance. What about performance?

Thank you for advice.

A: 

It's better to use separate includes in this case, since it yields a lot more readable and maintainable code. In general I'm rather strongly opposed to using echo statements to outputting HTML through PHP, for that reason.

Emil H
+7  A: 

Well some may disagree with this but in my opinion what makes PHP good is that it is first and foremost an HTML templating engine and classes/objects are really a sideshow to that. Your IndexHTML class doesn't really add a lot of value. IMHO you're better off just treating the .php files as .html files with some dynamic code blocks and expressions thrown in rather than trying to create an object model just for the sake of it.

cletus
Modifiability becomes a disaster with these setups.
Joe Philllips
Could not agree more with you cletus, and could not agree less with you d03boy. Would love it if, just once, the first reaction to these types of questions wasn't "use Smarty".
da5id
As for modifiability, you handle it like you did in the C days: functional decomposition. I've replaced 300k lines of badly written PHP with 20k lines of clean PHP where it's been pretty easy to throw together a new paginated table page with fairly minimal code (for example)
cletus
I don't disagree with this answer but I don't think it really provides any valuable insight into what to do. It just says what not to do.
Joe Philllips
Did you not see ". IMHO you're better off just treating the .php files as .html files with some dynamic code blocks and expressions thrown in rather than trying to create an object model just for the sake of it."?
cletus
+1. “class IndexHTML” gains you nothing at all except making the structure of the output more difficult to read and full of \-escapes. PHP is a templating language; use it don't fight it.
bobince
so the second way in my question is right?
perfectDay
Kind of. Why put the requires in a class though?
cletus
A: 

I make my own little controller with nothing but PHP code in it. I then have an html-include directory with my "views" in it named something like: myController.myAction.htm or myController.form.htm, etc. I then "include" the proper view, depending on my logic, at the end of my controller. This allows them to have access to all of my variables that I set up in the controller after any of my database transactions and business logic.

My favorite thing about this is that it's very simple and it allows tons of flexibility. It also can be pretty if you rewrite URLs and use a proper naming convention to organize your controllers and views.

Joe Philllips
A: 

Use smarty templates

L. Cosio
+1  A: 

There is no "proper way" of doing this in PHP, only various accepted "good practices" and many mediocre and just plain bad ones. PHP gives you a nice open space to do it however it makes sense to you. This is arguably its greatest strength. But this is also a big liability. Just because you can do it however you like doesn't mean you should.

I've seen numerous projects that do it all different ways. The methods currently en-vogue involve separating out data manipulation, data access and data presentation using a framework usually with a central dispatch controller. They have their own rules about how to arrange your directories and where to find the files.

An older method involved treating each file as a page. It had a few includes at the top of the file that setup the environment, including database handlers and other abstractions, but also defined functions for building the common elements of a page. The file was in two halves: it did all its processing and access in the first half, and then built its output in the second half. A variation of that has it include a separate file for the output. IME, this is closer to the spirit of PHP and is easier to make work from scratch.

staticsan
A: 

I'm new to PHP, but I've been programming Delphi for years. As with Delphi, there's no reason why you shouldn't be able to develop easily maintainable PHP code that combines logic and presentation. I tend to opt for code reusability in the form of modular functional elements connected through parameter passing (such as passing HTML with embedded variable names as a sort of template). Also, sometimes reinventing the wheel is the best way to learn about how the original wheel works, so instead of using third party templating software like Smarty, try developing your own template system with inspiration from Smarty.

Jared