Just use your own little script for this kind of thing; it doesn't
belong in the core of the language.
--Wez.
On Thu, 29 May 2003, George Whiffen wrote:
> 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.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
