When to use and when not to use OOP

[Captain Proton]

We wrote this site in 100% OO PHP4. We now have 5 webservers, 1 sql server, and 1 nfs/web server. Our old setup (using php nuke!) required 2 web servers, 2 sql servers, and 1 nfs/web servers.

Not exactly necessarily a fair comparison, eh?

- those 5 webservers could have P75s while the 2 webservers could have P2500's
- the new 100% OO PHP site may have tons of more features since the phpnuke site
- the coders might have been lousy compared to PHPNuke's coders (I know, theoretically...)

So you see, such a statement does not say anything about OO. Also, the fact that OO performs slow does not mean "OO sucks" it means that the language in which OO is written (in this case PHP) has a flaud OO implementation.

[lastcraft]

Hi...

looking into my crystal ball, I forsee a post in the near future telling us its OK and to just throw more hardware at it .... you can't argue with that since it totally ignores the issue.

Well...hardly.

Throwing more hardware at it is a valid option. Note the part "valid option". It's an option that is often not weighed correctly with a full ROI calculation. If you saved a month development time getting a product out early (that presumeably easily pays for that development time or why do it) then the business expansion will easily buy you another server or two. The problem with optimisation is that it can damage the code base unless it is very well factored (which takes time). That hurts the business long term in a big way. It shouldn't be done on the blind faith that it is the "right thing" to do regardless. It shouldn't be done because of fear. The decision is too one sided when done like that.

However, assuming that the development resources expended do not justify the extra threeish servers needed I still find something wrong here. I have rebuilt half a dozen pretty complicated systems and never managed to get a factor of two slow down moving code to OO . I would expect a 20 to 50% hit in the script running time (usually swamped by the DB) on unoptimised sections if I were being really lazy (OK, the norm). In fact because as the project grows OO produces less code, I tend to find the OO systems come out slightly faster. Something else is happening here. What else has changed during that rewrite?

What does the profiler say? Do the profiler times tie up with the Apache benchmark tool? Have you timed the Mysql queries from the console (in batch form if they are simple). Are you including the whole code base in every script you run? Are you using a templating system that is too complex or one that isn't compiled into PHP? What extra functionality was added during the rewrite? What other I/O is happening? Are you using a byte code cache? What are the session times? Pure web servers are usually cheaper boxes (IDE drives and the like) and half the cost of DB servers. How does the hardware compare? Basically where is that extra time going?

That is not to say you cannot overuse OO to create a load of objects you then only call one method on, but these things are easily fixed.

yours, Marcus

[firepages]

does not mean "OO sucks" it means that the language in which OO is written (in this case PHP) has a flaud OO implementation.

no , OO does not suck , nor does PHP , the only way you can say ( & I appreciate PHP's OO is still relatively basic) .. PHP's implementation is flawed, is in that it is an interpreted language , interpreted languages suffer more from the overhead of pure OO than compiled languages , perhaps someome will aregue that point as well but I do not see how ?

perhaps its the implementation of JAVA/.NET style page-object's and class heirarchy in an interpreted language (in a concurrent multi-user environment) that is flawed ?

Marcus , not going to disagree with your points above , but the liberal sprinkling of more hardware is as you know oft-quoted in these debates ,and I still think that that is not a valid answer, at least not until you have looked at all the other possible issues , some you have noted above and in other threads.

[lastcraft]

Hi...

...but the liberal sprinkling of more hardware is as you know oft-quoted in these debates.

Agreed absolutely. Both sides must be looked at and compared.

yours, Marcus

[Austin_Hastings]

Not exactly necessarily a fair comparison, eh?
- those 5 webservers could have P75s while the 2 webservers could have P2500's

Because lots of companies whose revenue stream depends on their website are replacing good hardware with crappy hardware?

- the new 100% OO PHP site may have tons of more features since the phpnuke site

I'm guessing that it does -- otherwise, why do the rewrite? On the other hand, it's valuable information in that the "size" of the website is roughly known -- this isn't a hello world app, but something roughly as complex as 'nuke.

- the coders might have been lousy compared to PHPNuke's coders (I know, theoretically...)

Granted.

So you see, such a statement does not say anything about OO. Also, the fact that OO performs slow does not mean "OO sucks" it means that the language in which OO is written (in this case PHP) has a flaud OO implementation.

Sure it says something about OO, and it says something about PHP4+OO, which is the real subject of this thread. It says, bluntly:

"OO is sufficiently popular in general and PHP4+OO is accessible enough that inexperienced developers can successfully produce a pure-OO site of advanced complexity. However, PHP4+OO is poorly implemented so that inexperienced developers tend to produce applications that have unacceptable performance."

... profiler ...? ... Apache ...? ... Mysql ...? ... including ...? ... templating ...? ... functionality ...? ... I/O ...? ... cache? ... session ...? ... hardware ...?

That is not to say you cannot overuse OO to create a load of objects you then only call one method on, but these things are easily fixed.

This, I think, pretty much damns PHP4+OO at the high end.

Had the application been coded in Perl, or C++, or Java, or even ASP, the immediate response would have been: "what did he do wrong?" Even taking into account Marcus' overcivilized English nature and bend-over-backwards-to-help temprament, that should be the first question asked of a PHP5 application with bad performance. But PHP4+OO isn't going to forgive you if you make certain non-beginner errors, and that's a problem.

A novice coder can successfully write an application that is well designed, decomposed into clear, logical, sensible modules, and that application is significantly likely to perform poorly under moderate load.

Ironically, this fact has helped me to become a better OO programmer. But I have the unfair advantage of being both smart and experienced (not to mention wealthy, attractive, and modest ), so I was on the lookout for problems of the sort.

Suspecting and confirming the performance issue has caused me to think about what my objects do, and the actual statement execution counts of my code. This has clarified how I code objects and it has definitely encouraged me to get away from the "objects = things" model that intro-to-OOP teaches. I think the "tell, don't ask" philosophy works well in PHP4+OO for this reason -- bigger, more functional, more "procedural" classes.

This:

$links= new LinkCollection();
$links->query_links(ALL_LINKS);
$links->print_list_of_links(); 

instead of this:

$links = Links::query_links_into_array(ALL_LINKS);
foreach ($links as $link) {
  $link->print_link();
} 

The subtle but important difference being that the aggregate object became an OBJECT in its own right, with methods that lower the call cost.

This is not to say that all PHP4+OO is bad -- most sites don't have the word "million" in their site statistics. And PHP4+OO is, as I've said, very accessible. I like it, or I wouldn't be posting here. But OO afficionados, especially "purists", need to acknowledge that there's a trap at work -- it's too easy for novices to write "OO" code that doesn't scale.

=Austin

[otnemem]

This:

$links= new LinkCollection();
 $links->query_links(ALL_LINKS);
 $links->print_list_of_links(); 

instead of this:

$links = Links::query_links_into_array(ALL_LINKS);
 foreach ($links as $link) {
   $link->print_link();
 } 

The subtle but important difference being that the aggregate object became an OBJECT in its own right, with methods that lower the call cost.

Must make you think twice before rushing to use those brand new iterators huh?

This is a common syndrome in people comming from a Java background (as well as other popular OO languages). A very good understanding of Object Oriented programming is evident most of the time, but they often got "bite" back by the performance of their application. Over-design comes at a big price in php!

I think the lesson is that not every implementation maps well to every platform. And good understanding of the technology (PHP in this case) is needed in order to use good patterns and implement them correctly.

just my 2 cents,

- Andres

BTW, there are some Content Management Frameworks that should take into account this -- including Austin's snippet.

[josheli]

it (the "Scalable Sessions" site) is one example in a sea of millions, and the variables are too many (as marcus and others pointed out) to go off making blanket statements about OO in php, either way (good or bad). Save the hyperbole and show us actual numbers, not one anecdotal example.

[lastcraft]

Hi...

However, PHP4+OO is poorly implemented so that inexperienced developers tend to produce applications that have unacceptable performance."

We are getting near to something, but I don't buy this argument in it's literal form. Starting OO is a little like starting software development all over again. However at the level of the PHP interpreter all it does is double the method dispatch times. If you code procedurally you could only approach this flexibility by passing function names or with eval(), both of which have much longer dispatches and screw up byte code caches to boot.

Doubling the dispatch time does not double the script time, because it is only a minor part of that script time. In fact the PHP interpreter seems to be the biggest delay so fewer lines of code is a greater benefit. Adding the Zend accelerator will often quintuple the script speed, for example.

I think the rewite produced problems that are only indirectly to do with OO. Most likely a lot more files are being parsed on each request or DB code has migrated into the application.

Had the application been coded in Perl, or C++, or Java, or even ASP, the immediate response would have been: "what did he do wrong?"

My response is still "what did (s)he do wrong"? People are blaming OO without first isolating the other factors involved. Why do they only need one DB server now? There have been some pretty major architectural changes for that to happen.

My gut feeling is that OO has very little to do with it.

Now C++ and Java are compiled, so it's not a direct comparison. You are trading performance for ease of deployment by using an interpreted system. Perl is more interesting to compare.

To code small objects in Perl is painfully difficult. It's almost impossible to write maintainable applications without resorting to the "Perl way" with all sorts of ties and blessing things on the fly. I don't think you can blame PHP for letting you do more complex tasks. If you want to do text processing then you have the wonderfully fast regexes, but otherwise it has no great performance advantage at OO. Compare Mason with PHP for example. As an aside Perl development takes us three to four times as long as PHP and we have relegated it to admin tasks whilst we switch to Ruby. You have to live Perl to be profficient in it.

I don't have any knowledge of typical Python or Ruby application performance or development times.

Even taking into account Marcus' overcivilized English nature and bend-over-backwards-to-help temprament,

Cough...

I think the "tell, don't ask" philosophy works well in PHP4+OO for this reason -- bigger, more functional, more "procedural" classes.

Ouch. It should lead to patterns like visitors and factories. I'd hate to see it used to create bigger classes.

I think the win is that you are more likely to get the data near the class that needs it, thus avoiding long dispatch chains through accessors.

But OO afficionados, especially "purists", need to acknowledge that there's a trap at work -- it's too easy for novices to write "OO" code that doesn't scale.

OO tends to be responsible for more complex applications. I suspect that the "novices" involved are already working at the limit of their knowledge and would find a procedural solution either impossible or no further improvement. But I'm guessing. We need more info.

Anyway, we can disagree all day and I have said "I think" enough times for one post . My experience so far just doesn't tally up with your assessment on this one (I agree with you on most subjects, honest). I have spent most of the last year optimising a pretty large PHP application that is performance (reponse time more than load) sensitive. In all that time the PHP scripts themselves have been negligible factors even when the server gets maxed out.

Admittedly this is with pretty complex logic and a few dozen processes per server. George Schlossnagle, etc, have similar things to say though about their high traffic work with probably simpler app. code. Look at the architecture first and the PHP code about fifth.

Something doesn't feel right about this problem.

yours, Marcus

[Gybbyl]

oop should be used for when you need to reuse the code effectively, to speed your website, and to enable your website to be dynamic

1. oop - object oriented programming, html is the complete opposite, it's static and is pointless to make a class to output it
2. effectively - creating a class to output html is static, how you have it setup it makes it not at all dynamic and very unstable, you only allow certain tags and are requiring an entirely different language to ineffectively parse something that can be parsed easy
3. speed - creating a class to output html is nonsense, one, it slows down the code, it takes up twice as much resources having to run it through the html parser and the php parser to acheive the same output
4. dynamic - oop is for a website so that it may be dynamic, dynamic as in reusing the code, and later down in the script being able to modify the object, play with it, and output it to your needs, html is static

Dude, I'm going to have to disagree with just about everything you said in that post.

HTML is object-oriented. Think about Java bean classes and other taglibs -- their entire functionality is encapsulated in a single tag. You use tags to represent one piece of data, which is just about the same thing you do in a class. You can call different attributes of that class, and you can call different attributes of a tag. Think about it. What do people use to represent objects in things like OO databases? XML. HTML is generally just a subset of (SGML) XML.

There are many libraries that are devoted to the output of HTML data via class calls. Because you can represent a tag so easily with a class, it creates a perfect opportunity to define a hierarchy for those tags (they fit SOO well in a hierarchy) which is why you have code in HTML like this:

<html>
    <body>
        <table>
            <tr>
                <td></td>
             </tr>
         </table>
     </body>
</html>

It fits perfectly within an object-oriented hierarchy. All elements have one super-element.

There are even projects devoted to the cause of outputting HTML in an abstracted manner with OO. Jakarta-ECS has a project, I believe.

You can allow every tag (there aren't that many to implement in HTML). You could even write a class library that didn't know ANYTHING about the HTML subset of SGML and make it be an XML library so that it may just "happen" to output proper HTML given the right user defined child classes.

Classes don't slow code down as much as people claim they do. Lazy and ignorant programmers slow code down, and they always somehow seem to be USING classes in their PHP code. PHP 5 has rectified many of these problems (value/reference confusion among programmers being the most notable).

HTML is parsed inside of the browser. HTML doesn't get parsed by the browser until PHP is done handing it to your webserver and then the server sends it to you. They are two completely unrelated things (the cycles aren't even taking place on the same computer). I can load nearly 300 files with an average of 200 lines each (about 20 characters per line) in about 1/3 of a second on questionable hardware. I can load any given HTML page with my old 133 Mhz gateway in about the same time (most of the time is getting the packets from the server into the NIC, and then from the NIC to my processor so it can do it's work).

We've already established that OOP and SGML subsets are in essence different manifestations of the same idea.

[McGruff]

"PHP4+OO is poorly implemented so that inexperienced developers tend to produce applications that have unacceptable performance."

This shifts the focus from php OOP to programmers' skills. Can we agree that you won't get punished for using OOP per se - but you will get punished for writing bad code of either flavour?

[Gybbyl]

but you will get punished for writing bad code of either flavour?

As you've adamantly argued in this thread, performance isn't really an issue in PHP since you can just upgrade to new hardware anyway

You (anyone) could argue that since you can potentially have a loop that runs n^2 times in a function, that functions are slowing down the code.

Why doesn't everyone just do what feels right to them and stop worrying about
a) what other people think about it
b) how "slow" their program is running
c) what kind of concepts they are applying when they program

If you want to use classes, USE THEM. There are so many kilobytes of text on this forum trying to advocate the use of classes. You could have spent that time improving your own program instead of trying to get someone else to write theirs with your mindset.

There will be times when you can use classes (and in my opinion should), but there are times when you just can't (when you are maintaining). Deal with it.

</incoherent post>

[lastcraft]

Hi...

You (anyone) could argue that since you can potentially have a loop that runs n^2 times in a function, that functions are slowing down the code.

At the extreme you could potentially argue a lot of things and program at a tenth of the pace in a state of constant terror. Or you could just measure it.

Why doesn't everyone just do what feels right to them and stop worrying about
a) what other people think about it
b) how "slow" their program is running
c) what kind of concepts they are applying when they program

Because?
1) Discussing these issues and swapping war stories makes us better programmers.
2) As developers we are prone to practice the abstract.
3) It's fun.

yours, Marcus

[been]

This might be slightly off-topic, but I thought I'd throw in a war story (If you've got a "been there, done that, bought the T-shirt feeling, I'm sorry for reiterating and glad you got out of the trenches )

A few days ago I was fiddling around with my own parser (Hey! A wheel! And an ugly one too!)
When I had a first version up & working, I ran it agains HarryF's XML_HTMLSax3, both were given the same html page, and I did a simply stoptime-starttime comparison between both parser's parse() method call.

"My" parser took around 30 secs, HTMLSax3 took 15 secs, both are fairly OO, they were just implemented differently, but the basic principles are the same.
This was just some personal work, so I didn't mind putting in some extra hours to investigate the difference in parsing time.
At one point, I refactored (method to class) the states to the point it seemed that my parser did the exact same thing as HTMLSax3, ran the same test, HTMLSax3 took around 15 secs, mine took around... 30 secs...

A few investigations later, I found what was causing the difference:
The parser uses a StringScanner, which is a basic class upon which different parsers could get built.
In that class, different methods are called for moving through a string and reading parts of it and returning them (scanning).
Internally, the scanner uses some properties: the current position in the string and the size (length) of the string. Both properties can be publically accessed through a getPosition() and size() method respectively.
Internally, those properties where also accessed by calling the methods and when the internal pointer has to be moved internally, the methods forward() and back() were called (basically increasing or decreasing the current position in the string). I always thought it was a good idea to call accessors instead of accessing properties directly, but when I removed these internal method calls to act on the properties directly, the parser performed up to par with HTMLSax3! (of course I don't access the properties directly outside the class! I don't think this is a case where one should break encapsulation for performance gain)

So, maybe an obvious lesson learned could be: "Don't try to reinvent the wheel", but if I didn't try it, I'd probably find out much later (if ever) that method calls have an impact when there are a lot of them during script execution (such as a parse process).
Another thing is that it would begin to look very ugly if I tried to implement this in a procedural manner (in which case I'd have a very hard time working away the global variables that'd hold the string position and length...)

[Selatos]

Well I believe that sharing concepts is a very good idea, because if you know how other people do stuff then you have a starting ground for your own projects, by applying patterns, etc. And if we debate the best method, then we know what generally works and what doesn't(certain solutions haven't been suggested because they are less desirable, for example).

For example, I've learned that there should be a reason for a class because of inherent flaws in PHP's OO implementation, where as I might have only wanted procedural, or only OO before hand, because I had one friend who told me what to do. Now, I have the opinions of lots of friends telling me what to do, and why, so i can pick what seems to be the best idea.

[McGruff]

Why doesn't everyone just do what feels right to them and stop worrying about
a) what other people think about it
b) how "slow" their program is running
c) what kind of concepts they are applying when they program

Because there are good ways to do things and bad ways to do things - and this forum is for discussing them.

OOP is a vastly better way to manage something as complex as a 'typical' web app (and we haven't even mentioned unit testing yet..). There are no disadvantages but many real and extremely practical advantages.

[Andrewaclt]

A common theme throughout this thread is seperating your display code from your logic code..but what about Harry's oop page class...(http://www.sitepoint.com/article/object-oriented-php/4 about half way down) Doesn't it violate this in addHeader/addFooter? Is there a better way to do this?

[Selatos]

Well, Harry's class is very static in that respect. I wrote my own Page construction class(which i've been trying to show you for the past two days, damnit). The way i did it was create a template for a header(standard tags, etc) and then add the content via function parameters.

//$doctype can be null incase someone doesnt want one for some reason
function addHTMLHeader($meta, $style, $doctype = null) {
//html header + doctype
$html = $doctype."<html>\n<head>\n";
//parse meta info into tags
foreach ($meta as $key => $val) {
$html .= '<meta ';
if (isset($val["name"]) {
    $html .= 'name="'.$val["name"].'"';
}
else {
     $html .= 'http-equiv="'.$val["http-equiv"].'"';
}
$html .= 'content="'.$val["content"].'" />'."\n";
}
//add title tags and a stylesheet tag
$html .= '<title>'.$this->title.'</title>'."\n";
$html .= '<link rel="stylesheet" type="text/css" href="'.$style.'" />'."\n</head>\n";
$this->page .= $html;
//the body tag will be done later in the page class
} 

The reason I did mine this way was so that I can literally "create" pages on the fly, I don't have static method code, only static parameters to those method calls, which lets me change the interfacing script rather than the class file. For example, look at the rest of the class--its simply HTML adding functions to "construct" a page:

//function to add the body tag
function addBody() {
$this->page .= "<body>\n";
}
 
//function to add content directly to the page
function add($content) {
$this->page .= $content."\n";
}
 
//function to add a link
function addLink($url, $title, $titletag = "") {
$this->page .= '<a href="'.$url.'" title="'.$titletag.'">'.$title.'"</a>'."\n";
}
///function to add a line break <br>
function addBreak() {
$this->page .= "<br />\n";
}
//function to add an image
function addImage($src, $alt, $class = "") {
$this->page .= '<img src="'.$src.'" alt="'.$alt.'" class="'.$class.'" />'."\n";
}
 
//functions to add a div
function startDiv($class) {
$this->page .= '<div class="'.$class.'">'."\n";
}
function endDiv() {
$this->page .= "</div>\n";
}
 
//functions to create tables
function startTable($class) {
$this->page .= '<table class="'.$class.'">'."\n";
}
function endTable() {
$this->page .= "</table>\n";
}
function startRow($class = "") {
$this->page .= '<tr class="'.$class.'">';
}
function endRow() {
$this->page .= "</tr>\n";
}
function startHeader($class = "") {
$this->page .= '<th class="'.$class.'">'."\n";
}
function endHeader() {
$this->page .= "</th>\n";
}
function startDialog($class = "") {
$this->page .= '<td class="'.$class.'">'."\n";
}
function endDialog() {
$this->page .= "</td>\n";
}
 
//function to close the body
function closeBody() {
$this->page .= "</body>\n";
}
//function to close the HTML
function closeHTML() {
$this->page .= "</html>";
}
//function to close the page
function closePage() {
$this->closeBody();
$this->closeHTML();
} 

I'm sure that Harry knows more about this than I do, and there is probably a very good reason for the method he uses, but I prefer to seperate the logical application code from the static HTML code, not have them grouped together making the class more static. I like non-denominational classes a lot more than ones I need to update for each site I make.

[Gybbyl]

There are no disadvantages

No disadvantages? I might not totally agree with that.

There are disadvantages to everything -- their is no perfect solution for software engineering.

Would you use an OO language to write a shell program that was 25 lines long? (aka too long for saying "that's not a real program" and too short to make writing the interface and class implementation worthwhile).

[Mike Borozdin]

Selatos, I wonder how you use that class, can you show some examples? Do you create the whole page by using this class? If so, I think it's not convenient to edit it afterwards, especially if you work with a designer who doesn't know PHP.

I think such classes are great for editing an existing page, so you just specify the file and then you can bind data to tables, edit links and so on.

[The New Guy]

That seems like a pretty useless class to me. I think you time would be better spent making a template engine, instead of making a function for every possible HTML tags, which will then require you to learn not only HTML but your functions, which is a waste of time to me.

[Widow Maker]

I think you time would be better spent making a template engine, instead of making a function for every possible HTML tags,

You are going to have serious headaches later if for example you need to implement another markup language, XML for example

But regardless of that point, if I was to do something like you have, and rest asured, I wouldn't I can promise you that, I would have had a base class to manage the HTML, HEAD and META side of things, and then sub class for TABLEs for example ?

Then another sub class for DIVs, etc etc. Harry has an example of building a page on the fly via the DOM, and this is a far better approach.

But in saying that, if you do need to continue to use your class(es) as is, then I would have a template shell - just a page structure - and then append new data via your classes to it ?

That way, it'll save you some repeatitive scripting at least

[Selatos]

Widow Maker, I'm one step ahead of you, I didn't post the class I derived from it . I have another class, called TemplatePage, which implements a basic template structure, like so:

class TemplatePage extends Page {
var $values;
var $template;
//$title is the title of the page
//$template is html file with <php*> tags
function TemplatePage($title, $template) {
$this->template = file_get_contents($template);
$values = array();
$this->title = $title;
$this->set("<phptitle>", $title);
}
//erases everything already there, use only the first time or not at all
function set($key, $val) {
$this->values[$key] = $val;
}
//appends to the value, preserving anything thats already been added
function append($key, $val) {
$this->values[$key] .= $val;
}
//an error has occured
function panic($message) {
$this->set("<phperror>", $message);
//doesnt dump the Page buffer, because it doesn't know where to put it
$this->show();
@die();
}
//write the page to the template
//clears the page
//$show = true|false, decides whether to show it after writing or not
function writePage($key, $show = false) {
$this->append($key, $this->page);
unset($this->page);
if ($show) {
$this->show();
}
}
//show function
function show() {
foreach ($this->values as $key => $val) {
//slip the variables into the file, if something isnt defined it wont affect it
$this->template = ereg_replace($key, $val, $this->template);
}
echo ($this->template);
}
} 

Just so everyone knows, I've got a third class, derived from this one, which does page caching, but I'm still deciding on the best method(serialization, database, files, etc) to use to cache it, so that class is relatively incomplete. What I was trying to achieve was something like this: I can include a template, and then create things like a nav menu section USING the calls to startdiv(), etc. then add it to the template in the same method i would add static html, using append() or set(). Example code:

$template = new TemplatePage("Test", "main.tpl.html");
$template->startDiv();
$template->add("content here.");
$template->endDiv();
$template->writePage("<phpbody>", true); 

main.tpl.html:

<html>
<head>
<title>
<phptitle>
</title>
<link rel="stylesheet" href="<phpstyle>" type="text/css" />
</head>
<body>
<div>
<phperror>
</div>
<phpbody>
</body>
</html>

Basically, I split the two classes like that to keep the HTML generating code seperate from the template usage code. I don't use the first class exclusively, like you said--its a headache to maintain, but I DO use it to create specific elements of the page that aren't a part of the template. By doing it this way, I can create more generic templates(allowing me to reuse them) and add calls like those illustrated above in included files to add things like navigation.

[Widow Maker]

Okay, I see now - an improvement though personally I wouldn't have went down the road you've taken ?

$template->add("content here.");
... 

This point, I think your adding content ?

In my case, my scripts don't directly add content, but they append a View class(es) which these are template fragments (derived from MVC) so my template class once it has all the appended Views, then it'll gather all the (by this time) generated HTML from the individual Views (template fragments) ? ie

# controller
$page = &new Page( 'news.tpl', 'default.shell.tpl' );
$page -> Register( 'title', 'This is the news page' );
...
$view = &new NewsView;
$view -> Put( &$datamodel );
$page -> Append( &$view );
...
return $page // back to page dispatcher
... 

Then, at the dispatcher, I'd have

...
$page = $cntrl -> Execute();
$page -> Finalise(); // execute each View appended
$page -> Render(); // output
... 

So I have a template shell, which can have one or more template fragments, with each or any template fragment it's self having it's own fragments

Very flexible in that sense, though does mean you need a class per template fragment though

[Selatos]

Very nice. So what you do is make a template out of templates? Like....mini-templates fitting into the puzzle that is the bigger template? Thats a pretty good idea, I might have to rewrite my class(third time in a week, ahh) to include some sort of interface for something like this. After I code my version of it, would you mind looking over it and telling me if I'm on the right track(i'll probably do this tomorrow, or finish it then if i start tonight)?

I think that it could be accomplished by having a Template class(like mine but ill add some more functionality, and inherit the Page class i wrote just incase i want that too), and then create a Fragment class. You said that you need a new class per fragment, well I can just create a standard set of function calls for all of the fragments by having them derive and override the correct functions to change functionality.

[Andrewaclt]

Does anybody besides selatos have a take on my previous post as how to handle a page class (and regards to Harry's article on sitepoint?)? Selatos way looks a bit pointless imho...

As a sidenote - besides the GoF is there any suggested reading (webbased or not) about basic oop design?