include() and require() pick up the whole file. Could we have the option to include just part of the file?
Proposed new syntax for include(), require():
include ( string filename [, string start_tag [, string end_tag]])
If the optional start_tag is specified, the file is only read from immediately after the first occurrence of the start_tag string in the file. If the optional end_tag is also specified, reading of the file stops with the last character before the end_tag.
Example:
include('layout.html',"<!-- section header -->\n","\n<!-- section");
with layout.html as follows:
<!-- section header --> <html> <head> </head> <body> <img src="banner.gif"> <h1> Some standard title</h1> <table width="700"> <tr> <td> <!-- section middle --> Some php output <!-- section footer --> </td> </tr> </table> <h2>Complaints to <A HREF="<?= $email?>" me</A><h2> </body> </html>
would include only the header section, i.e.:
<html> <head> </head> <body> <img src="banner.gif"> <h1> Some standard title</h1> <table width="700"> <tr> <td>
Purpose:
At least for me, it is very common for at least the header and footer of every page to be prepared and maintained by an html developer as part of a "standard" layout. Individual php generated html pages "include" the header, then write their own output and finally "include" the footer.
With the current include()/require(), the header and footer MUST be stored in individual files. They have to be "cut out" of the standard layout design page and stored in separate files e.g. header.txt and footer.txt. From then on, the html developer has to maintain them individually without the benefit of viewing them together in the layout page via their html editor.
With partial includes available, the layout page could be used directly to provide the header, footer, navigation and any other standard includes while still being easily maintainable and viewable as a whole by non-php html developers using standard html editors.
I believe this is a common scenario where partial includes would save time and significantly improve maintainability. There are plenty of other possible uses. It could just as well be mail text, xml, or plain old php code that you might prefer to handle in sections of one file rather than being forced into placing each section in a separate include files.
Implementation:
With the proposed syntax, implementation shouldn't be too bad. It's really just an extra couple of string scans i.e. the php equivalent would be something like:
$code = get_file_contents($filename);
$startpos = strpos($code,$start_tag);
if ($startpos)
{
$startpos = $startpos + strlen($start_tag);
$endpos = strpos($code,$end_tag,$startpos);
if ($endpos)
{
$code = substr($code,$startpos,$endpos - $startpos);
} else {
$code = substr($code,$startpos);
}
}
eval('?>'.$code.'<?');There is no need for regex or tokenizing, and it's the user's responsibility to decide if they want to keep or lose trailing/starting new lines, enclosing comment tags etc.
The trickiest question is where/when to do the scans to pick out the appropriate section of the file. The most obvious candidate is probably Zend/zend_language_scanner.c:zend_read_file(). This seems to be where an include file is actually read. Unfortunately it's pretty deep into the code and I don't suppose anyone would want to change it without at least having Zeev/Andi/Whoever's go-ahead.
As to performance, my guess is it would be significantly faster than an include of two separate files: after the first include there's a fighting chance of finding the include file still in O/S file/disk cache for second and subsequent accesses.
What do you all think?
George.
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
