If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

And home.php (or any other page that gets included here, depending on the parsing of query parameters) may contain other stuff as well, such as SQL queries, invocation of E-mail / captcha / form / other classes, and what not. Crude but effective.

But now I am faced with a need to modify the page header include file on the basis of variables that get defined in the content include file. For example in home.php there could be something like

$pageTitle = 'Home';

which would then have to be used in the header.php include, as in:

echo '<title>' . $pageTitle . </title>' . "\n";

Which means that I have no shot myself in the foot, since the header has been included (and has executed it's 'echo' statements) before the content file (with the declarations needed in the header) is loaded up only after that.

Fixing it involves breaking my straightforward process flow - i.e. I would have to put the statements that output the header into the content include (e.g. home.php) which I find highly inelegant... Or even worse, I would have to store entire chunks of HTML content in large memory-consuming variables, manipulate them later, and output them only after modification, which also breaks my straightforward process flow _and_ means higher server load and delayed output and other impediments to performance that I don't want.

So. Suggestions anyone? Clearly I need to so something very simple and sensible here, but i just can't see it. Any idea's would be appreciated!

I suppose the "best" solution would depend on how much time/work you can put into it. Perhaps the quickest would be to do an ob_start() at the beginning of the main script, then at whatever point you have all the data you need, do a ob_get_clean() and assign its result to a variable. Then you can use str_replace() or preg_replace() to change the values of the title, keywords, etc.; then echo that variable to output the page to that point.

The opposite end of the spectrum would be to implement a MVC framework such as CodeIgniter, CakePHP, etc. or a templating system such as Smarty.

Perhaps in between would be to functionalize your header stuff so that it can take parameters for the title and other variable data, then call the functions from the content page once it has the data?

I suppose the "best" solution would depend on how much time/work you can put into it.

Well, I have a number of legacy code chunks, and I'm somewhat lazy, so obviously I'm looking for a "least effort" optimum here... :-) But I realize that that may not be possible.

Originally Posted by NogDog

Perhaps in between would be to functionalize your header stuff so that it can take parameters for the title and other variable data, then call the functions from the content page once it has the data?

I would rather output the header before getting to the content part. I'd like to keep that nice and separated - headers are headers, and part of the preliminaries to be completed before we concentrate on the content part and nothing else. Calling a function (or initiating another action) that causes the header to be rendered from within an include that should only contain the meat of page content strikes me as fundamentally wrong, inelegant, unintuitive, etc...

Maybe I'm just too much of a purist... but experience tells me that if I'm unhappy with a certain approach and go ahead with it anyway, sometime later I am going to wish I hadn't. :-)

Anyway, thanks for your suggestions. At least they will help me think!

This is probably a good illustration of why MVC and similar patterns try to separate the presentation layer (i.e. the View) from the other processing (i.e. the Model and Controller).

Perhaps you can at least split your "content" into two files: one that does the "business process" and populates variables and arrays based on the request type/data, then you can include the header, content-output, and footer files, allowing them to access that data.

This is probably a good illustration of why MVC and similar patterns try to separate the presentation layer (i.e. the View) from the other processing (i.e. the Model and Controller).

Agreed. It also illustrates the perils of having grown up in the procedural world of ANSI C and then, many years later, trying to plod through the 21st century as a self-taught PHP hack. :-)

If I had followed a proper approach of functionalizing my output operations, using classes and objects instead of libraries and procedures, I would not be stuck like I am. But they didn't have them newfangled thingies in my youth, so when I jumped into PHP about 6 years ago I took the procedural approach, which now comes back to haunt me. :-)

Originally Posted by NogDog

Perhaps you can at least split your "content" into two files: one that does the "business process" and populates variables and arrays based on the request type/data, then you can include the header, content-output, and footer files, allowing them to access that data.

The least inelegant kludge that I have managed to come up with is to keep a separate array of page request keys (the same used later on to include the appropriate content file) and use that to retrieve values for the various header properties. So before including the header and the pagecontent file specified by, say, $queryParms['p'] I will do something like