Apologies in advance if internals is not for feature requests.
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.
Just use your own little script for this kind of thing; it doesn't
belong in the core of the language.
--Wez.
Apologies in advance if internals is not for feature requests.
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.