Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:2073 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 39445 invoked from network); 28 May 2003 21:56:27 -0000 Received: from unknown (HELO secure.thebrainroom.com) (213.239.42.171) by pb1.pair.com with SMTP; 28 May 2003 21:56:27 -0000 Received: from zaneeb.brainnet.i (IDENT:root@brain.dial.nildram.co.uk [195.149.29.154]) by secure.thebrainroom.com (8.9.3/8.9.3) with ESMTP id WAA05204; Wed, 28 May 2003 22:56:25 +0100 Received: from zaneeb.brainnet.i (IDENT:wez@zaneeb.brainnet.i [127.0.0.1]) by zaneeb.brainnet.i (8.11.6/8.11.6) with ESMTP id h4SLuQ813600; Wed, 28 May 2003 22:56:26 +0100 Date: Wed, 28 May 2003 22:56:26 +0100 (BST) X-X-Sender: wez@zaneeb.brainnet.i To: George Whiffen cc: internals@lists.php.net In-Reply-To: <3ED5409A.2010802@whiffen.net> Message-ID: References: <3ED5409A.2010802@whiffen.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [PHP-DEV] include() - partial includes? From: wez@thebrainroom.com (Wez Furlong) 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',"\n","\n > > > > > >

Some standard title

> > > > >
> > Some php output > >
>

Complaints to

> > > > would include only the header section, i.e.: > > > > > > >

Some standard title

> > >
> > 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 > > >